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(57) Abstract 

Coordination system for 
distributed programmes, services and 
data using application programs in a 
computer network where coordinating 
servers (21, 22, 23) run local software 
systems (18,19,20). Common objects 
(9) are used as communication 
objects for information exchange and 
transactions are used to carry out 
communication. Communication objects 
(9) are clearly identified by means of 
object identification numbers (OID) 
and only processes with reference to a 
communication object are allowed to 
access this on one local coordinating 
server or another. All coordinating servers (21,22, 23) are set up as a global operating system (24); local software systems (18,19,20) are 
extended by functions for transaction control, for the creation and blocking or non-blocking reading of communication objects, to specify 
transactional predicates and to produce and monitor clearly identified authorized processes enabling access to transferred communication 
objects and communication objects (9) are managed with the assistance of selectable replication based distribution strategies from which 
application programs are independent. 
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(57) Zusammenfassung 

System zur Koordination verteilter Programme, Dienstlcistungen unci Daten mit Hilfe von Anwendungsprogrammen in einem 
Netzwerk mit Rechnern, auf denen lokale Softwaresysteme (18, 19, 20) bedienende Koordinations-Server (21, 22, 23) laufen, wobei 
gemeinsame Objekte (9) als Kommunikationsobjekte zum Austausch von Nachrichten eingesetzt und Transaktionen zur Realisierung von 
Kommunikation verwendet werden, und die Kommunikationsobjekte (9) durch Objektidentifikationsnummern (OID) eindeutig identifiziert 
werden und nur Prozesse mit einer Referenz auf ein Kommunikationsobjekt auf dieses uber den jeweiligen lokalen Koordinations-Server 
zugreifen durfen; hierbei werden alle Koordinations-Server (21, 22, 23) zusammen als globales Betriebssystem (24) festgelegt, werden 
die lokalen Softwaresysteme (18, 19, 20) durch Funktionen zur Kontrolle von Transaktionen, zum Anlegen und blockierenden oder 
nicht-blockierenden Lesen von Kommunikationsobjekten, zur Spezifikation von transaktionalen Pradikaten sowie zur Erzeugung und 
Oberwachung von eindeutig identifizierten, zum Zugreifen auf ubergebene Kommunikationsobjekte autorisierten Prozessen erweitert, und 
werden die Kommunikationsobjekte (9) mit Hilfe von auf Replikation beruhenden wahlbaren Verteilungsstrategien verwaltet, von denen 
Anwendungsprogramme unabhangig sind. 
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Koordinations- System 

Die Erfindung betrifft ein System zur Koordination 
verteilter Programme, Dienstleistungen und Daten mit Hilfe von 
Anwendungsprogrammen in einem Netzwerk mit Rechnern, auf denen 
lokale Sof twaresysteme bedienende Koordinations -Server laufen, 
wobei gemeinsame Objekte als Kommunikationsobjekte zum Austausch 
von Nachrichten eingesetzt und Transaktionen zur Realisierung 
von Kommunikation verwendet werden, und die Kommunikationsob- 
jekte durch Objektidentif ikationsnummern eindeutig ident if iziert 
werden und nur Prozesse mit einer Referenz auf ein 
Kommunikationsobjekt auf dieses uber den jeweiligen lokalen 
Koordinations -Server zugreif en diirf en . 

Unter Objekten sind allgemein fur sich abgeschlossene Ein- 
heiten zur verstehen, die sowohl Daten als auch bestimmte 
Verhaltensweisen enthalten, und die mit der Aufienwelt durch 
Austauschen von Nachrichten kommunizieren bzw. zusammenarbeiten . 
Die Aufienwelt ist dabei insbesondere wiederum durch andere 
Objekte gebildet. Beispielsweise konnen Kunden ( -Dateien) , aber 
auch Rechnungen oder Lief erscheine Objekte bilden. Unter Trans- 
aktionen sind andererseits Einheiten von Aktionen zu verstehen, 
die ublicherweise bestimmte Eigenschaf ten, namlich Atomizitat, 
Konsistenz, Isoliertheit und Dauerhaf tigkeit , erfullen mussen. 
Die Ergebnisse von Transaktionen mussen gegen Fehler jeglicher 
Art geschiitzt werden. Diese Forderungen werden in der Literatur 
als ACID-Eigenschaf ten bezeichnet und sind in der Praxis vor 
allem bei Datenbankzugrif f en von Bedeutung, insbesondere wenn 
parallele und koordinierte Veranderungen verschiedener Eintrage 
erfolgen sollen. Wenn nun in diesem Fall eine Transaktion nicht 
vollstandig durchfiihrbar sein sollte, so konnte dieser Umstand 
zu einem inkonsistenten Datenbestand f uhren . Wesentlich ist hier 
demgemaS, date eine derartige Transaktion entweder zur Ganze 
richtig oder gar nicht durchgefiihrt wird (Atomizitat) . 

Die rasante Entwicklung von Netzwerktechnologien, die auch 
zur weltweiten Einfuhrung von Internet gefiihrt hat, bringt immer 
mehr neue Anwendungsgebiete mit sich, wie etwa das Erstellen von 
Programmen durch Koordinieren von im Netz verteilten Programm- 
stiicken und Ressourcen anstatt der Erstellung von sequentiellen 
Programmen, und das Einkaufen von Dienstleistungen im Netzwerk. 
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Die hierfiir erf orderliche Sof twareunterstutzung muS ein hohes 
Ma£ an Zuverlassigkeit und Verf iigbarkeit garantieren. 

Bei bekannten Systemen (siehe z.B. auch EP 574 3 03 A oder 
US 5 555 427 A) werden in erster Linie Nachrichten zur 
Kommunikation und zur Synchronisation von parallel laufenden 
Aktivitaten ausgetauscht (sog. "message passing"). Beispiels- 
weise wird bei vielen bekannten Systemen mit speziellen Auf- 
rufen, den RPC-Aufrufen ("Remote Procedure Call"), eine Funktion 
auf einem anderen Rechner im Netz - mit Parameteriibergabe usw., 
ahnlich wie bei Aufrufen einer lokalen Funktion - aufgerufen. 
Diese Form von Nachrichtenaustausch zwecks Kommunikation und 
Synchronisation zieht jedoch verschiedene Nachteile nach sich. 
So ist es notwendig, auf zugrundeliegende Hardware -Architekturen 
eingehen zu miissen, wobei auch zumeist die Anpassung von 
Anwendungsprogrammen an neue Hardware -Umgebungen oder aber neue 
Anwendungsanf orderungen hinsichtlich Effizienz, Zuverlassigkeit 
und Verf iigbarkeit das Modifizieren des Programmcodes erf ordert . 
Weiters nehmen diese in der Literatur als Client/Server-Archi- 
tekturen bezeichneten Systeme (siehe z.B. auch US 5 3 81 534 A) 
dem Programmierer weder die Synchronisation von gleichzeitigem 
Datenzugriff noch die Replikation von Daten ab. Programme, die 
mit solchen Systemen erstellt werden, weisen naturlicherweise 
eine hierarchische Struktur auf und zerfallen in Client- 
Komponenten und in Server- Komponenten, die beide vom 
Programmierer zu erstellen sind. Die hierarchische Struktur 
fuhrt bei groSen Anwendungen auch zu Performance -Problemen . 

Alternative Ansatze zum Nachrichtenaustausch basieren auf 
der Verwendung gemeinsamer Daten (Objekte) fur die Kommunikation 
und Synchronisation parallel laufender, verteilter Prozesse . Der 
Vorteil dieses Ansatzes ist, daS bei gleicher Machtigkeit eine 
konzeptionell hohere Abstraktion der zugrundeliegenden Hardware 
geboten wird. Programme, die auf diesem Paradigma basieren, 
konnen kurzer und besser wartbar sein. Weiters konnen Systeme, 
die gemeinsame Daten bieten, dem Programmierer bei der 
Erstellung von Programmen deren "Server " -Komponente abnehmen. 

Allerdings weisen die existierenden Ansatze, die auf 
gemeinsamen Daten beruhen, in der Regel mehrere der folgenden 
Nachteile auf: 
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(a) Es gibt globale Namen fur die Objekte, was bei groSen 
Datenmengen sehr schnell zu Namenskonf likten fiihrt und die 
Moglichkeit, automatisch Objekte aufzuraumen, unterbindet . 

(b) Die Verwaltung der Objekte bietet keine Ausf allsicherheit 
^ bei Netzwerk- und Systemf ehlern . 

(c) Der Losungsansatz ist nicht in jede beliebige Programmier- 
sprache einbettbar, d.h. moglicherweise nur in Form einer 
neuen Sprache verfiigbar. 

(d) Die Atomizitat mehrerer Kommunikationsschritte wird nicht 
geboten . 

(e) Transaktionen werden in der Regel nicht unterstiitzt. In den 
wenigen Ausnahmen werden nur klassische Transaktionen unter- 
stiitzt, was fur die Koordination verteilter Systeme nicht 
ausreichend ist. Ein f riihzeitiges (nicht isoliertes) 
"Kommit" (Vollzugsmeldung) von Untertransaktionen ist nicht* 
moglich, so da£ Zwischenergebnisse von kooperierenden 
Transaktionen nicht sichtbar gemacht und Sperren in lokalen- 
Systemen nicht fruhzeitig aufgehoben werden konnen; gerade 
diese beiden Moglichkeiten waren aber wesentlich fur die 
Autonomie lokaler Systeme.. Weitere in Zusammenhang mit 
Transaktionen wiinschenswerte Eigenschaf ten waren eine 
semantische Kompensation (die benotigt wiirde, urn trotz 
Aufhebung der Isolation .von Transaktionen Atomizitat 
garantieren zu konnen) und eine Funktionsreplikation, die 
vorsieht, Teiltransaktionen im Fehlerfall durch andere 
ersetzen zu konnen. 

(f) Es wird genau ein Verfahren zur Verwaltung der konsistenten 
Sicht des logisch gemeinsamen Objektraums auf der verteilten 
Hardware geboten. Damit ist der Programmierer dem System 
hinsichtlich erreichbarer Fehlertoleranz und Performance- 
moglichkeiten ausgelief ert . 

(g) Das Anbieten von Dienst leistungen , die mit Hilfe der gemein- 
samen Daten realisiert wurden, wird nicht unterstiitzt. Eine 
benutzerspezif ische Unterscheidung ware besonders 
wiinschenswert . 

(h) Das Entfernen nicht langer benotigter Daten wird nicht 
automatisch unterstiitzt . 

(i) Es gibt keine Zugrif f skontrolle : jeder, der den Namen eines 
Objekts errat, darf darauf zugreifen. 
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(j) Es gibt keine Moglichkeit, die Berechnungen, die die Objekte 
verwenden, hinsichtlich Wiederherstellbarkeit , nachdem 
Fehler auftreten, zu unterstiitzen . 
(k) Das Verhalten des Systems ist unspezif iziert bzw. sind alle 
Daten verloren, wenn ein partieller Fehler auftritt, d.h. 
wenn beispielsweise auch nur einer der beteiligten verteil- 
ten Rechner einen fatalen Systemabsturz aufweist, bei dem 
z.B. die Daten der Festplatte zerstort wurden. 
In den Aufsatzen 11 Fault -Tolerance for Communicating Multi- 
database Transactions", eva Kuhn, Proceedings of the 27th Hawaii 
International Conference on System Sciences, ACM, IEEE, 4 bis 7 
Janner, Hawaii, 19 94, Seiten 323-332; "General Purpose Work Flow 
Languages", Alexander Forst, eva Kiihn und Omran Bukhres, Inter- 
national Journal on Parallel and Distributed Databases, Software 
Support for Work Flow Management, Kluwer Adademic Publishers, 
Band 3, Nr. 2, April 1995, Seiten 187-218; "Logic Based and 
Imperative Coordination Languages", Alexander Forst, eva Kuhn, 
Herbert Pohlai und Konrad Schwarz, Proceedings of the PDCS 1 94 , 
Seventh International Conference on Parallel and Distributed 
Computing Systems, ISCA, IEEE, Las Vegas, Nevada, Oktober 6-8, 
1994, Seiten 152-159; und "A Parallel Logic Language for Trans- 
action Specification in Mult idatabase Systems", eva Kiihn, Ahmed 
K. Elmagarmid, Yungho Leu, Noureddine Boudriga, International 
Journal of Systems Integration, Vol. 5, 1995, Kluwer Academic 
Publishers, Boston, Seiten 219-252, sind bereits Anregungen fur 
daruber hinaus gehende Losungen enthalten, wie insbesondere der 
Einsatz von lokalen Koordinations-Servern, welche lokale 
Software -Systeme bedienen, und iiber die die Transaktiorien zur 
Realisierung von Kommunikation zwischen Objekten durchgefiihrt 
werden sollen. In diesem Zusammenhang wurden auch verschiedene 
Sprachen-unabhangige bzw. in beliebige Programmiersprachen 
einzubettende Prozeduren gefordert, wie etwa urn Transaktionen zu 
beginnen, zu beenden oder abzubrechen. Uberdies wurde bereits 
allgemein eine Replikationsstrategie angesprochen, gemafi welcher 
jede Stelle, die auf ein Kommunikationsobjekt zugreift, ihre 
eigene Kopie erhalt, wobei jedoch eine Kopie als Hauptkopie oder 
primare Kopie von den iibrigen Kopien, den sekundaren Kopien, 
unterschieden wird. Eine solche primare Kopie wird angelegt, 
wenn ein Kommunikationsobjekt angelegt wird. Wenn dieses 
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Kommunikationsobjekt zu einer anderen Stelle gesendet wird, wird 
eine sekundare Kopie angelegt und dem Koordinations-Server an 
der anderen Stelle gesendet. Dadurch wird letztlich eine 
Baumstruktur erhalten, in der jeder Knoten jene Knoten kennt , an 
die eine Kopie gesandt wurde , und jeder nachfolgende Knoten 
(Sohn) den iibergeordneten Knoten (Vater) kennt, von dem er die 
Kopie erhalten hat. Am Wurzelpunkt des Baumes liegt die primare 
Kopie des Kommunikationsob j ektes vor. 

Diese in den genannten Artikeln enthaltenen Anregungen waren 
richtungsweisend, jedoch ermoglichten sie noch keine praktische 
Durchfiihrung der Koordination von verteilten Software - Syst emen , 
Dienstleistungen oder Daten. Insbesondere wurden von diesen 
Ansatzen zwar bereits die obengenannten Nachteile (a) bis (e) 
angesprochen, jedoch vor allem fur die Probleme (f) bis (k) noch 
keine Losungen aufgezeigt. Von den zu losenden Problemen ist das 
Problem (f) von ganz besonderer Wichtigkeit, da das Argument, 
daS nur mit Low-Level -Nachrichtensenden bzw. Client /Server- 
orientierten Architekturen eine maximale Performance - 
allerdings auf Kosten von wesentlich mehr und auf wendigerer 
Implement ierungsarbeit - erreicht werden kann, der Hauptgrund 
dafiir ist, dafi sich bisher Ansatze mit gemeinsamen Objekten 
nicht durchsetzen konnten. 

Aufgabe der Erfindung war es daher, ein neues System der 
eingangs angefiihrten Art vorzusehen, das die Erstellung von 
robusten verteilten Anwendungen, wie z.B. sog. Arbeit sprozefi- 
("Work Flow" ) -Management systemen, Systemen fur verteiltes 
kooperatives Arbeiten ("CSCW"), Mulitdatenbanksystemen, ver- 
teilten Hypertext -Syst emen usw. , in einfacher und zuverlassiger 
Weise ermdglicht, wobei die vorstehend genannten Nachteile 
bekannter Vorschlage durch besondere Transaktionskonzepte auf 
der Kommunikationsschicht sowie durch die Auswahlbarkeit von 
mehreren Verteilungsstrategien vermieden werden sollen. 

Das erf indungsgemafie System der eingangs angefiihrten Art ist 
dadurch gekennzeichnet , 

daS alle Koordinations-Server zusammen als globales 
Betriebssystem festgelegt sind, 

dafi die lokalen Sof twaresysteme zumindest durch Funktionen 
zur Kontrolle von Transaktionen, zum Anlegen und blockierenden 
oder nicht -blockierenden Lesen von Kommunikationsobjekt en, zur 
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Spezif ikation von transaktionalen Pradikaten sowie zur Erzeugung 
unci Uberwachung von eindeutig identif izierten, zum Zugreifen auf 
ubergebene Kommunikationsob j ekte autorisierten Prozessen 
erweitert sind, 

und daS die Kommunikationsobjekte mit Hilfe von auf Repli- 
kation beruhenden wahlbaren Verteilungsstrategien verwaltet 
werden, von denen die Anwendungsprogramme unabhangig sind. 

Mit einem solchen System bzw. mit dem damit geschaffenen 
Koordinationsparadigma wird eine vorteilhafte Alternative zu den 
herkommlichen Client /Server- Architekturen erhalten, wobei 
zahlreiche, nachstehend erlauterte Vorteile erzielt werden. 

Durch das Verhalten der Gesamtheit aller Koordinations- 
Server als weltweites, einheitliches Betriebssystem - wozu die 
Koordinat ions -Server untereinander ident sind - werden unter 
anderem die Vorteile erzielt, daS eine einheitliche Behandlung 
gesichert ist, daS Anzahl und Orte der Rechner - oder Agenten - 
keine Rolle spielen (es wird mit dem vorliegenden System ein 
spezif isches Netzwerk erhalten) , und daS im Falle von verlorenen 
Objekten zumindest jene Teile, die von den verlorenen Objekten 
unabhangig sind, repariert bzw. als konsistente Gesamtheit 
gerettet werden konnen. Ferner wird die Programmerstellung mit 
Hilfe des globalen Betriebssystems wesentlich einfacher. Die 
Programmierung der Synchronisation und Replikation von Daten 
wird dem Programmierer abgenommen. Die Programme werden 
einfacher, kiirzer und daher besser wartbar. 

Beim vorliegenden System werden globale Namen fur Ob j ekte 
vermieden - jeder ProzeE bekommt in seiner Argument liste die 
Obj ekt identif ikationsnummern aller fremden Ob j ekte mit, die er 
sehen darf , wobei er nur iiber diese Obj ektidentif ikationsnummern 
zugreifen kann; andererseits miissen in verteilten Systemen 
gewisse Obj ekte doch aufgrund einer Bezeichnung bezogen werden 
konnen (z.B. "WWW Browser" etc.), und dies ist beim vorliegenden 
System moglich. In der geschlossenen Koordinations-Server-Welt 
werden nur Objektidentif ikationsnummern verwendet, und diese 
konnen nach aufien beispielsweise iiber an sich bekannte bzw. 
vorhandene Unterstutzungen, die iiber Datenbankmechanismen eine 
Referenz auf ein Objekt (sowie ein Zugrif f srecht ) retournieren, 
und die hier der Einfachheit halber "Nameserver" genannt werden, 
export iert werden. Diese Nameserver konnen auf Basis von 
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vorhandenen Unterstiitzungen, unter Verwendung von bekannten 
Datenbanktechnologien, auf Applikationsebene realisiert werden, 
und dabei kann, auf die jeweiligen Bediirfnisse zugeschnitten, 
ein entsprechender PaSwortschutz bzw. ein Accounting- und 
Indexingmechanismus etc., der iiber die Koordinations -Server- 
Mechanismen noch hinausgeht, hinzugefiigt werden. Die technische 
Realisierung nutzt die Tatsache permanenter Server aus, bei 
denen ein unendlich lange laufender Prozefi als autonomer und 
automatisch wiederherzustellender ProzeS lauft, dessen Argument 
der Startpunkt zur Liste aller verwalteten Namen/Ob j ekte ist . 
Dieser ProzeS darf nie terminieren und exportiert die gewiinschte 
Objektidentif ikationsnummer an Anfrager, die den Namen der 
Obj ektidentif ikationsnummer angeben und deren Anfrage als ProzeE 
auf eben diesem Server durchgefiihrt wird. Damit sind beliebige 
Domanen von Nameservern realisierbar , die in eingeschrankten 
Bereichen kontrolliert globale Namen verwalten. 

Das Sicherheitsproblem ist ausreichend gelost, indem nur 
Prozesse, die rechtmaSig eine Objektidentif ikationsnummer be- 
sitzen - die ihnen entweder mitgegeben wurde, die von ihnen 
selbst erzeugt wurde, oder die erlaubterweise iiber einen 
Nameserver bezogen wurde -, auf Obj ekte zugreifen diirfen. Damit 
wird iiber die Mechanismen des Betriebssystem hinaus - die vom 
Koordinations -Server-Modell auch gewahrt werden - noch weitere 
Datensicherheit garantiert . 

Ein weiterer Vorteil der erf indungsgemafien Losung ist, dafi 
das Spezif izieren von Dienstleistungen und das Exportieren 
dieser Dienstleistungen an spezifische Benutzer und Gruppen 
unterstiitzt wird. Das erfolgt beim Konf igurieren der 
(x/transienten) Server, bei denen angegeben werden kann, wer die 
jeweilige Dienstleistung konsumieren darf. 

Eine wichtige neue Eigenschaft ist die Unterstiitzung von 
Kommit -Aktionen, deren wesentlicher Vorteil darin liegt, daS der 
Programmierer Berechnungen und das Schreiben von Daten atomar 
zusammengruppieren kann. Es kann beispielsweise zum Ausdruck 
gebracht werden, da£ ein neuer "Worker" gestartet werden mu&, 
wenn ein bestimmter Wert kommuniziert wurde. Dieser Sachverhalt, 
der auch, wenn die gewahlte Verteilungsstrategie zuverlassig 
ist, iiber System- und Netzwerkf ehler hinweg garantiert wird, 
macht die Entwicklung von f ehlertoleranten Applikat ionen sehr 
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einfach. Daruber hinaus kann man davon ausgehen, daS alle 
benotigten Daten automatisch wiederhergestellt werden, und da£ 
alle autonomen Prozesse, die noch nicht terminiert hatten, 
automatisch wieder angestartet werden. 

Durch die wahlbaren Verteilungsstrategien (Kommunikations- 
protokolle) ist ein Fein-Abstimmen von Zuverlassigkeit , Verfiig- 
barkeit, Replikationsverhalten bzw. Performance der Kommuni- 
kationsobjekte je nach Bedarf und Zielsetzung moglich, z.B. 
durch wahlweise bestimmbare Protokollf lags , wie "zuverlassig 
(reliable) " / "nicht -zuverlassig (unreliable)"; es konnen auch - 
in einem Programm - verschiedene Verteilungsstrategien gleich- 
zeitig, fur verschiedene Kommunikationsobjekte , existieren. 

Daruber hinaus werden sowohl nur einmal beschreibbare als 
auch aktualisierbare Objekte unterstiitzt, die unterschiedliche 
Vorteile bieten - diese Ko-Existenz ist sonst von keinem 
existierenden System bekannt . 

Ferner wird durch die Funktionserweiterung bzw . -erganzung 
der lokalen Sof twaresysteme , somit die Erweiterung von deren 
Sprachen zu sog. Koordinations-Sprachen, nicht nur die 
Kommunikation mit £em globalen Betriebssystem bei Verwenden von 
ansonsten herkommlichen Programmiersprachen (z.B. C, Prolog, 
Java, Fortran, . ermoglicht (abgesehen vom gewunschten 
Operieren mit den Kommunikationsobj ekten, Transaktionen etc.), 
sondern auch - liber das globale Betriebssystem - eine Uber- 
setzung zwischen den verschiedenen Sprachparadigmen erhalten, so 
daS die Kommunikationsobj ekte sprachunabhangig sind (und jede 
beliebige Art von Daten enthalten konnen) ; das globale Betriebs- 
system besorgt auch die eventuell erf orderlichen Umsetzungen bei 
verschiedenen Datenf ormaten (z.B. 32 Bit-/64 Bit-Datenworte ) und 
Endiantypen ( l, big"/"little t ' ) . Hinsichtlich dieser Funktionser- 
weiterung bzw. -erganzung existieren als Moglichkeiten der 
"Bibliotheks-Ansatz" (bei dem der Programmiersprache die 
gewunschten Funktionen hinzugefiigt werden) Oder insbesondere der 
"Einbettungs-Ansatz" (bei dem die Koordinationseigenschaf ten in 
die Programmiersprache "eingebettet " , d.h. integriert werden). 

Die Erfindung ergibt somit ein in einer ganz spezifischen 
Weise operierendes System bzw. Netzwerk, in dem die verteilten 
Rechner gemaS einem gemeinsamen, globalen Betriebssystem laufen; 
insgesamt erbringt die Erfindung eine wesentliche Vereinf achung 
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in der Koordination von Sof tware-Systemen, Dienst leistungen und 
Ressourcen . 

Als besonders gunstig hat es sich erf indungsgemafi erwiesen, 
wenn bei der Wahl der jeweiligen Verteilungsstrategie eine 
Basisstrategie in Verbindung mit zusatzlichen, optionalen Stra- 
tegieflags gewahlt wird. Fur die Feinabstimmung der jeweiligen 
Verteilungsstrategie konnen hier zumindest verschiedene 
zusatzliche Strategief lags gewahlt werden, bevorzugt aber auch 
eine von mehreren moglichen Basis -Strategien . 

Weiters ist es von Vorteil, wenn die lokalen Sof twaresysteme 
vom jeweiligen Koordinations-Server gestartet werden. Hierbei 
ist es moglich, den Server als permanenten Server einmal zu 
starten, der dann an bleibt und weiteren Funktionen dienen kann, 
und der auch im Fall von verschiedenen Anwendern nur einen Namen 
erhalt; es ist aber auch denkbar, den Server als (x/-) transien- 
ten Server fur jeden Aufruf gesondert (bzw. auf einem Rechner zu 
einer bestimmten Zeit als alleinigen Server) zu starten. 

Urn den Speicher nicht iiber Gebiihr zu belegen, ist es weiters 
vorteilhaft, wenn Kommunikationsobjekte , auf die kein lokal 
laufender Prozefi mehr eine Referenz hat, vom jeweiligen Koordi- 
nations-Server automatisch geloscht oder ausdrucklich freige- 
geben werden. Dadurch werden nicht mehr benotigte Kommunika- 
tionsobjekte in der Art eines "Auf raumens" (sog. "Garbage 
Colllection") selbsttatig aus dem Speicher geloscht, so dafi 
Speicherplatz gespart wird; dies wird durch die Verwendung der 
nicht -globalen Ob j ektidentif ikationsnummern ermoglicht und auch 
dadurch begiinstigt, dafi die lokalen Sof twaresysteme vom Koordi- 
nations-Server gestartet werden. Damit kann der Koordinations- 
Server leicht erkennen, wann ein Prozefi terminiert hat, und dann 
die Ref erenzahler aller Objekte, die dieser Prozefi besitzt - das 
sind alle Objekte, die durch ihm iibergebene Obj ektidentif ika- 
tionsnummern bezeichnet werden, ferner alle Objekte, die der 
Prozefi selbst angelegt hat, sowie alle Objekte, die Unterobjekte 
von dem Prozefi zugangigen Objekten sind - dekrementieren . Die 
Loschung ist selbstverstandlich abhangig von der jeweiligen 
Verteilungsstrategie, die diese Loschung verzogern kann, bis 
Strategie-spezif ische Bedingungen erfullt sind. 

Im Hinblick auf eine optimale Nutzung von Moglichkeiten bzw. 
Ressourcen im Netz ist es auch von Vorteil, wenn iiber die sich 
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in ihrer Gesamtheit als globales Betriebssystem verhaltenden 
Koordinations-Server heterogene Transaktionen bzw. Unter- 
Transaktionen auf verschiedene Rechner verteilt werden. 

Vorzugsweise wird im Falle von aktualisierbaren Objekten 
( "updateable objects") ein transaktionales Lesen dieser Objekte 
vorgesehen. Auf diese Weise kann beim Kommit der Transaktion 
uberpruft werden, ob der gelesene Wert noch aktuell ist . 

Unter den transaktionalen Pradikaten wird vorzugsweise das 
Schreiben in ein Objekt, das Starten einer Untertransaktion, das 
Verteilen eines Teils einer Transaktion auf einen anderen 
Rechner, das Spezif izieren einer Kompensationsaktion bzw. einer 
Kommit-Aktion vorgesehen. Andere transaktionale Pradikate konnen 
beispielsweise das Testen eines Objekts im Hinblick auf (Un-)De- 
finiertheit, das Lesen eines aktualisierbaren Objekts oder das 
Loschen einer transaktionalen Anforderung (eines transaktionalen 
Requests) sein. Insbesondere ist es hier auch vorteilhaft, da£ 
dann, wenn sicher ist, dafi eine jeweilige Transaktion eine 
Vollzugsmeldung abgeben (kommitten) wird, eine Kommit-Aktion als 
Berechnung angestartet wird. 

Im Zusammenhang mit der Kpntrolle von Transaktionen konnen 
nicht nur das Starten und Abbrechen bzw. Zuriicknehmen von 
Transaktionen schlechthin vorgesehen werden, ebenso wie das 
Kommitten einer Transaktion in einer Form, in der eine Trans- 
aktion automat isch abgebrochen wird, wenn das Kommitten nicht 
erfolgreich ist: urn Transaktionen unter Rettung von bereits 
erfolgter Transaktionsarbeit reparieren zu konnen, kann mit 
Vorteil unter den Funktionen fur Transaktionen auch ein program- 
mierbares Riicksetzen von transaktionalen Operationen, wie z.B. 
das Lesen oder Schreiben von Kommunikationsobjekten, fur den 
Fall von Fehlern bzw. Ausf alien in den Transaktionen vorgesehen 
werden. Der Grund dafiir liegt darin, daS koordinierende Trans- 
aktionen im Gegensatz zu klassischen Transaktionen oft eine sehr 
lange Lebensdauer haben konnen und mit Hilfe der beschriebenen 
Rucknahmeeigenschaf t beispielsweise eine Transaktion, die schon 
lange, z.B. viele Monate, gelaufen ist und teure System- 
ressourcen konsumiert hat, in der aber eine eher unwichtige 
Operation oder Untertransaktion nicht erfolgreich war, dynamisch 
repariert werden kann, ohne damit auf die bereits geleistete 
Transaktionsarbeit verzichten zu mussen (in fruheren Losungen 
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ware ein Abbruch unabdingbar) . Dafur wird eine "schwache" Form 
der Kommit-Funktion, die nicht automatisch den Transaktions- 
abbruch bedingt, sondern eine Information dariiber retourniert, 
welcher transaktionale Befehl nicht erfolgreich abgeschlossen 
wurde, in Kombination mit dem dynamischen Riicksetzen von 
transaktionalen Befehlen verwendet . 

Die Erfindung wird nachstehend anhand von bevorzugten 
Ausf uhrungsbeispielen, die insbesondere Einzelheiten einer 
zumindest derzeit als besonders vorteilhaft angesehenen 
Ausf uhrungsf orm der Erfindung betreffen, auf die sie jedoch 
nicht beschrankt sein soil, sowie unter Bezugnahme auf die 
Zeichnung noch naher erlautert . Ira einzelnen zeigen in der 
Zeichnung : 

Fig.l ein Prinzipschema zur Veranschaulichung eines Systems, 
in dem Kommunikationsob j ekte fur autonome lokale Sof twaresysteme 
in einem globalen Raum zuganglich sind; 

Fig. 2 ein Schema, das die grundsatzliche Architektur einer 
Konf iguration mit Rechnern an verschiedenen Orten 
veranschaulicht , wobei in den einzelnen Rechnern installierte 
Koordinations- Server zusammen ein globales Betriebssystem 
def inieren; 

Fig. 3. ein logisches Ablauf schema zur Veranschaulichung des 
prinzipiellen Betriebs der Koordinat ions - S e rve r , und damit des 
globalen Betriebssystems ; 

Fig. 4 in einem logischen Ablauf schema die Behandlung lokaler 
Requests ; 

Fig. 5 den allgemeinen Ablauf beim Anlegen und Inspizieren 
von Kommunikat ionsob j ekten ; 

die Fig. 6 bis 8 zu Fig. 5 gehorige Funktionen in 
FluSdiagrammen ; 

Fig. 9 mehr im Detail den Ablauf der aus Fig. 4 ersicht lichen 
Transaktionskontrolle ; 

die Fig. 10 bis 16 zugehorige Transaktionen; 

Fig. 17 den Ablauf von Transaktionalen Befehlen (gemaS Fig. 4) 
mehr im Detail; 

die Fig. 18 bis 23 zugehorige Transaktionale Befehle 
(Transaktionsmanager ) sowie Unter-Prozeduren hierzu ; 

Fig. 24 den Ablauf im Fall von aus Fig. 4 ersichtlichen 
ProzeS-Bef ehlen mehr im einzelnen; 
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die Fig- 25 bis 31 den Ablauf der zugehorigen Prozesse, die 
zusarnmen den Prozefimanager ergeben; und 

die Fig. 32 bis 4 0 den Strategiemanager , d.h. verschiedene 
Prozeduren, die eine sog. Verteilungsstrategie (ein 
Kommunikationsprotokoll ) def inieren. 

In Fig.l sind schematisch verschiedene autonome Software- 
systeme (lokale Sof twaresysteme - LSYS) 1 bis 7 veranschaulicht , 
denen verschiedene herkommliche Programmiersprachen P x , P 2 , 
P 3 ....P n _l, P n (wie z.B. C, Prolog, Lisp, Pascal, Fortran, 
Cobol, C++ usw.) zugrundeliegen konnen. Die autonomen Software- 
systeme 1 bis 7 konnen dabei als gleichzeitig laufende Prozesse 
dargestellt werden, und sie konnen jeweils als eindeutig defi- 
niertes System mit einer solchen Programmiersprache angesehen 
werden; die Systeme 1 bis 7 konnen insbesondere je ein lokales 
Sof twaresystem sein, in dem jeweils eine andere 

Programmiersprache zugrundeliegt , so daS diese Systeme 1 bis 7 
nicht direkt miteinander arbeiten konnen. (Theoretisch ware es 
auch denkbar, da£ zwei Systeme direkt interaktiv sein konnen - 
diese direkt interaktiven Systeme werden hier der Einfachheit 
halber als ein System angesehen, und es konnen gegebenenf alls 
auch mehr Systeme, z.B. drei, so zusammengef a£t sein.) 

Mit 8 ist in Fig.l weiter ein sog. Agentenraum veranschau- 
licht, wobei die jeweiligen, nachstehend noch naher zu erlau- 
ternden Agenten Objekte 9 bis 17 zur Verfiigung stellen. Diese 
Objekte 9 bis 17 sind hier beispielsweise einmal beschreibbare 
("write-once") Objekte, gegebenenf alls auch aktualisierbare 
( "updateable" ) Objekte, und sie konnen als Einheiten oder 
Behalter mit Kommunikationsdaten angesehen werden; sie bilden 
Kommunikationsobjekte, die in dem gemeinsamen, den verschiedenen 
lokalen Systemen 1 bis 7 zuganglichen "Objektraum" enthalten 
sind. Zugang zu den einzelnen Kommunikationsobj ekten 9 bis 17 
ist dabei nur iiber einen der Agenten moglich. 

Eine Hauptaufgabe der Agenten besteht darin, den gleichzei- 
tigen Zugang zu Objekten 9 bis 17 so zu ermoglichen, daS alle 
Teilhaber, die diese Objekte 9 bis 17 sehen durfen, zu jeder 
Zeit die selbe konsistente Sicht von ihnen haben. Insofern liegt 
eine Ahnlichkeit zu einem verteilten Datenbanksystem vor, das 
Transaktionen an den, mehreren Teilnehmern zuganglichen 
Datenobj ekten bietet . 
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Das Management von Aktivitaten umfafit auch die Spezif ikation 
von Aufgaben, d.h. von Programmen, die durch bestimmte Software - 
systeme auszuffihren sind. Eine abgegebene Prozefi-Anf orderung 
(ProzeS- "Request " ) kann als Vertrag zwischen dem anfordernden 
Sof twaresystem und einem der Agenten betrachtet werden, der 
dafiir verantwortlich ist, dafi die Aufgabe von einem bestimmten 
(anderen) Sof twaresystem durchgefuhrt werden wird. Der Start 
einer Berechnung ist der Beginn einer neuen Interaktion zwischen 
dem Anfragenden und dem Durchf uhrenden . 

Die Objekte sollen alle Arten von kontrollierbaren Ausf alien 
in den Systemen iiberleben. Wenn bestimmte Umstande eingetreten 
sind, miissen sie bestehen bleiben, da global sichtbare Umstande 
nicht geloscht oder geandert werden konnen, nachdem andere 
Prozesse sie gesehen und ihre Berechnungen auf ihnen aufgebaut 
haben. Es ist notwendig, sich auf die iibermittelten Daten ver- 
lassen zu konnen. Sobald ein write-once Objekt ein definiertes 
Objekt (d.h. ein "nicht- leerer Behalter" ) wird, ist es eine 
konstante "GroSe" mit hoher Zuverlassigkeit . Es kann beispiels- 
weise (im Falle der write-once-Objekte ) nicht derart manipuliert 
werden, daS es zu einem spateren Zeitpunkt andere Daten enthalt. 

Aktivitaten werden implizit synchronisiert , da dann, wenn 
ein System vom Ergebnis eines anderen Systems abhangig ist, es 
weiS, welches Objekt die Daten enthalt, und es einfach darauf 
zugreifen kann. Wenn die Daten noch nicht bereit sind, wird ein 
System, das auf sie zugreifen will, einfach eine langere 
Zugrif f szeit benotigen. 

Fur die vorstehenden Anf orderungen werden im vorliegenden 
System die nachf olgenden, nachstehend noch naher erlauterten 
Koordinat ions " werkzeuge 11 vorgesehen, die in die einzelnen 
lokalen Systeme und Programmiersprachen eingebaut werden: 

- die Kommunikationsobjekte bilden einen zuverlassigen; 
abstrakten Kommunikationsmechanismus 

- es werden spezif ische Transaktionsf unktionen vorgesehen; und 

- es werden spezielle Sprachkonstrukte zur Sicherung von 
Parallelitat vorgesehen. 

Alle Stellen, die an einer Kommunikation teilnehmen, haben 
eine einheitliche Sicht der von ihnen geteilten ("shared") 
Datenobjekte . Auf die Objekte kann zugegriffen werden, als 
wiirden sie in einem lokalen Rechner vorliegen und in das 
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jeweilige Sof twaresystem derartig eingebettet sein, daS sie von 
lokalen Daten praktisch nicht unterschieden werden konnen. 
Insofern kann dann, bei entsprechender Einbettung in die lokale 
Software (was eine entsprechende Erganzung derselben hinsicht- 
lich Funktionen bedingt; Ausf lihrungsbeispiele zur Erganzung der 
Semantik der Basisf unktionen der Softwaresysteme, urn mit den 
Kommunikationsobjekt en zu operieren, werden nachfolgend noch 
naher erlautert) , die Kommunikation iiber diese Objekte als 
Kommunikationsmedien erfolgen, wobei iiber diese Kommunikations- 
objekte auch verschiedene Softwaresysteme kommunizieren konnen, 
da aus ihrer Sicht diese Kommunikationsobjekte wie lokale 
Objekte erscheinen. Fur den Programmierer stellt sich das System 
als global verfugbarer Raum dar, auch wenn dieser tatsachlich 
iiber eine Vielzahl von Stellen verteilt ist, vergleichbar einer 
grofien verteilten Datenbasis. Jeder interaktive Prozefi hat sein 
eigenes Fenster in diesen globalen Raum, aber alle Prozesse 
haben dieselbe Sicht auf das Objekt. Wenn Daten noch nicht 
verfiigbar sind, muS ein ProzeS wart en, anstatt mit nicht - 
aktuellen Daten zu operieren. In einem derartigen lokalen Raum 
halt der ProzeS in iiblicher Weise lokale Daten. Die Datentypen 
im lokalen Raum und im globalen Raum miissen selbstverstandlich 
kompatibel sein. 

Die Kommunikationsobjekte konnen von beliebigem Typ sein, 
d.h. es kann nur einmal ein Wert zugeordnet werden, oder sie 
konnen wie Variable aktualisierbar sein. Jeder ProzeS kann sich 
auf die aus dem globalen Raum ausgelesenen Daten verlassen, da 
sie (im Fall von write-once Objekten) sich nicht andern bzw. 
wiederherstellbar sind. Die Kommunikationsobjekte haben weiters 
eine eindeutige Identif ikationsnummer , jedoch keinen globalen 
Namen. Diese Objektidentif ikationsnummern (OID) werden zweck- 
maSig iiber die bereits erwahnten Nameserver exportiert, die auf 
Applikationsebene unter Verwendung bekannter Datenbanktechno- 
logien realisiert werden. Die Kommunikationsobjekte werden 
zwischen Prozessen durch Ubergabe als Argumente geteilt . Ein 
Prozefi, der keine Referenz auf ein Kommunikationsobjekt besitzt, 
erhalt keinen Zugang zu diesem. Der Agent, der die Kommunika- 
tionsobjekte unterhalt, hindert Prozesse daran, den Bezug auf 
ein Kommunikationsobjekt zu "erschleichen" . Auf diese Weise wird. 
eine Sicherheit insofern gewahrleistet , als nur berechtigte 
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Prozesse Zugriff zu den Daten haben . 

Ein Kommunikationsobjekt kann strukturiert sein, und es kann 
andere Kommunikationsobjekte als Komponenten enthalten. Derarti- 
ge Sub-Kommunikationsobjekte sind neue "Kommunikationsbehalter 11 , 
die Werte unabhangig vom sie umschlieEenden Kommunikationsobjekt 
erhalten konnen. Dies wird nachstehend anhand eines Beispiels 
(Beispiel 1: Produzent - Konsument - Problem) noch mehr im Detail 
auf gezeigt werden . 

Damit alle Prozesse, denen Kommunikationsobjekte gemeinsam 
sind, eine konsistente Sicht dieser Objekte haben, konnen Werte 
nur durch Transaktionen in den global geteilten Raum geschrieben 
werden . 

In vorteilhaf ter Weise moglich sind beim vorliegenden 
Koordinat ions -System weiters Funktionsreplikation, Aufgabe der 
Isolations -Eigenschaft von ineinander geschachtelten 
Transaktionen sowie eine semantische Kompensation . 

Die Funktionsreplikation fuSt auf der Notwendigkeit , eine 
Dienstleistung, die nicht gutging, durch eine andere zu 
ersetzen, die dieselbe Aufgabe in aquivalenter Weise erfullt. 
Auf diese Weise kann eine komplexe Aufgabe, die aus einer Anzahl 
von Unterauf gaben zusammengesetzt ist, zu Ende gefuhrt werden, 
selbst wenn ein lokales System ausfallt. 

Die Aufgabe der Isolatipns-Eigenschaf t ist aus zwei Griinden 
von Bedeutung: Zum einen wiirde dann, wenn beim Koordinieren von 
lokalen Datenbanksystemen eine Unteraktion Sperren im lokalen 
Datenbanksystem sowie das Halten dieser Sperren bis zum Ende der 
globalen Aktion erfordern wiirde, das Autonomieprinzip wesentlich 
beeintrachtigt werden. Insbesondere waren dann langlebende oder 
auch "ewige" Prozesse (wie der Produzent- Konsument -ProzeS, s. 
nachf olgendes Beispiel 1) ein bedeutendes Problem. Aus diesem 
Grund durfen Sub-Transaktionen vollenden (in der Datenbank- 
Terminologie : Kommitten) , bevor der GesamtprozeS beendet wird. 
Zum anderen erfordert ein kooperatives Arbeiten, dafi Zwischen- 
ergebnisse sichtbar werden, bevor der globale ProzeS terminiert . 
Unterauf gaben konnen nicht auf Daten von anderen Unterauf gaben 
warten, bis der globale ProzeS zu Ende gefuhrt ist. 

Die semantische Kompensation ist sodann die logische Folge 
der Aufgabe der Isolations-Eigenschaf t . Es kann beispielsweise 
der Fall eintreten, daS nach erf olgreichem AbschluS eine Aktion 
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nicht benotigt wird (etwa zufolge Funktionsreplikation) oder 
eine Aktion verworfen werden mu£ (wenn die globale Aufgabe 
endgultig scheitert) . Eine Transaktion, die "kommittet " wurde, 
darf jedoch nicht ruckgangig gemacht werden, da andere autonome 
Prozesse moglicherweise bereits ihre Ergebnisse "gesehen" und 
ihren Berechnungen zugrunde gelegt haben. Wenn ein Prozefi spater 
entscheidet, dafi eine Transaktion nicht benotigt wird, muE 
hierfiir eine semantische Kompensation vorgesehen werden. Eine 
vom Benutzer definierte Kompensationsaktion kann fur diesen 
Zweck spezifiziert werden, und sie wird dann automatisch 
aktiviert und kann ein anderes Kommunikationsobjekt schreiben. 

Da die zu koordinierenden Sof twaresysteme bereits existieren 
und an verschiedenen Stellen parallel laufen, ist Parallelitat 
im System erf orderlich. 

Die Parallelitat zwischen Prozessen ist wesentlich fur die 
gegenseitige {Coordination, und sie kann durch entsprechende 
Spracherweiterung vorgesehen werden, wodurch ein ProzeS (an 
einer anderen) Stelle erzeugt und gesteuert werden kann, und 
wodurch Kommunikationsobjekte ubergeben werden konnen, die 
zwischen der einen Stelle und der anderen Stelle, wo der neue 
Prozefi hervorgeruf en wird, geteilt (ge " shared" ) werden. Die 
Rechner-Stelle und das Sof twaresystem, wo der Prozefi ausgefiihrt 
werden soli, konnen spezifiziert werden. Von vornherein wird die 
jeweilige lokale Stelle als solche angenommen, und der ProzeS 
wird als Prozefi (wenn moglich als sog. "thread") des Systems, 
durch das er aufgerufen wurde, durchgef uhrt . Dadurch wird eine 
ausreichende Parallelitat zwischen den Prozessen sichergestellt . 
An sich ist Parallelitat innerhalb eines Prozesses nicht 
notwendig fur das vorliegende Koordinations-System, wohl aber 
Parallelitat zwischen Prozessen. 

Die vorstehend im Zusammenhang mit Fig.l erwahnten Agenten 
werden durch lokale Serverprozesse dargestellt, die 
Koordinations-Server genannt werden. Uberall, wo das vorliegende 
Koordinations-System laufen soil, muS ein derartiger 
Koordinations-Server vorhanden sein, der das jeweilige lokale 
Sof twaresystem erganzt und bedient, wie sich auch aus dem 
Architektur-Schema von Fig. 2 ergibt . 

Im einzelnen ist gemafi Fig. 2 an verschiedenen Stellen bzw. 
Rechnern X, Y, Z zusatzlich zu den lokalen Sof twaresystemen 18, 
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19, 20, die durch die nachstehend noch naher zu erlauternden 
Erganzungen fur das vorliegende Koordinations-System erweitert 
sind (was durch die Bezeichnung Sc Co" bei den jeweiligen Pro- 

grammiersprachen P 1 , P 2 p n-l' p n' also P i & Co, P 2 & Co, P 3 

& Co....P n _i & Co, P n & Co, angedeutet ist) jeweils ein 
Koordinations -Server 21, 22 bzw. 23 vorhanden. Diese Koordina- 
tions-Server 21, 22, 23 sind die vorerwahnten "Agenten" (s. auch 
Schraffur in Fig.l und 2) und definieren so den vorstehend 
anhand von Fig.l erlauterten "Agentenraum" , und sie bilden 
zusammen ein globales Betriebssystem 24. Zu diesem Zweck sind 
die Koordinations -Server ( "CoKe" - "Coordination Kernel") 21, 22, 
23 untereinander gleich ausgebildet, und es ist gleichgultig fur 
die Bildung des globalen Betriebssystems , wie viele Koordi- 
nations-Server 21, 22, 23 im Einzelfall vorhanden sind. Dieses 
globale Betriebssystem 24 fiihrt dazu, dafi es fur den Beniitzer 
gleich ist, ob ein ProzeS lokal oder an einer entfernten Stelle 
lauft; die identen Koordinations -Server 21, 22, 23 verhalten 
sich gleich, und durch diese Globalitat ergibt sich eine 
Datenabstraktion; ein Zugriff auf ein Objekt an einer entfernten 
Stelle verhalt sich wie ein Zugriff auf ein lokales Objekt - der 
Beniitzer merkt hier keinen Unterschied, uhd er sieht in diesem 
Zusammenhang keine Nachrichten. 

GemaS Fig. 2 wird beispielsweise das Objekt 9 vom Agenten 
(Koordinations -Server) 21 angelegt und sodann zu den Agenten 22 
und 23 weitergereicht . Die Agenten fungieren dabei als verteilte 
" Transakt ionsmanager " . Ganz allgemein kann jeder Koordinations - 
Server als die Module (1) Transakt ionsmanager ; (2) ProzeS- 
manager; (3) Strategiemanager ; (4) Recovery- (Wiederherstell - ) 
manager enthaltend angesehen werden. 

Das globale Betriebssystem 24 ergibt sich hinsichtlich 
seiner allgemeinen Funktion aus Fig. 3 und mehr im Detail 
hinsichtlich der Transakt ionskontrolle aus Fig. 4 bis 9 in 
Verbindung mit den Fig. 10 bis 23 (Transaktionsmanager) ; der 
Proze£manager ist aus Fig. 24 in Verbindung mit den Fig. 25 bis 31 
ersichtlich, und der Strategiemanager (der aus Einzel -Managern 
SMi fur die jeweilige Verteilungsstrategie besteht) aus den 
Fig. 32 bis 40. 

Der Recoverymanager , auf den z.B. in den Fig. 13, 14, 15 
sowie 28, 30 und 32 bezug genommen wird, enthalt die folgenden 
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wesentlichen Elemente : 

Atomarer Schritt START 

Atomarer Schritt ENDE 

Atomarer Schritt ABBRUCH 
Dabei werden Aktionen, die zwischen START und ENDE 
passieren, entweder alle ausgefuhrt, oder keine davon; d.h. bei 
einem Systemf ehler zwischen START und ENDE wird keine Aktion 
durchgef iihrt . 

Je nach der verwendeten Strategie (unter Setzen von Flags) 
erfolgt die Ausfiihrung zuverlassig (ausf allsicher ) , d.h. Effekte 
werden in Log- und Datenfile protokolliert (gespeichert ) , oder 
nicht zuverlassig . 

Dises Verfahren gilt auch fur einen geschachtelten Aufruf 
von START /ENDE. 

Bei einem Aufruf von "Atomarer Schritt ABBRUCH" werden alle 
Effekte annuliert . 

In Fig. 3 ist der prinzipielle Arbeitsablauf , namlich die 
Hauptschleif e , des vorliegenden Systems, und zwar im Bereich des 
globalen Betriebssystems 24 bzw. des jeweiligen Koordinations- 
Servers 21, 22 oder 23, in Form eines Flufidiagramms schematisch 
veranschaulicht . Wie dabei ersichtlich ist, wird nach einem 
Initialisierschritt 25 und einem Wiederherstellschritt 26, in 
dem alle vom Koordinat ions -Server 21, 22 bzw. 23 benotigten 
Daten vom Datenfile oder vom "Logfile" wiederhergestellt werden, 
sowie einem Schritt 27, in dem ein unabhangiger , noch nicht 
terminierter , momentan nicht aktiver Prozefi P definiert wird, 
beim Schritt 28 abgefragt, ob die ProzeEliste P leer ist, d.h. 
ob kein solcher ProzeS P gefunden wurde . Wenn dies nicht 
zutrifft, wird der ProzeSmanager aufgerufen, urn - gemaS Block 2 9 
- den ProzeS P auf zuspannen, wonach zum Schritt 27 zuriickgekehrt 
wird. Das Aufspannen eines Prozesses ist ein Unterprogramm, das 
nachstehend anhand der Fig. 31 noch naher erlautert werden wird. 

Wenn das Abf rageergebnis bei 28 positiv ist, d.h. kein 
ProzeS P vorliegt, wird im Schritt 30 zur Ausfiihrung getrigger- 
ter Arbeit iibergegangen, und im Schritt 31 wird auf ein nachstes 
Ereignis E gewartet . Im Schritt 32 wird dann abgefragt, ob 
dieses Ereignis E eine Nachricht von einem anderen Koordina- 
tions-Server ist. Falls dies nicht zutrifft, wird sodann bei 33 
abgefragt, ob das Ereignis E ein Request von einem lokalen 
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Sof twaresystem ist; falls nein, wird das Ereignis E im Schritt 

34 als Konsolen-Befehl behandelt; falls ja, wird das Ereignis E 
als lokaler Request behandelt, und zwar gemafi einer mit Block 3 5 
angegebenen Prozedur, welche nachstehend anhand der Fig. 4 noch 
naher erlautert wird. Ist hingegen das Ereignis E eine Nachricht 
von einem anderen Koordinations-Server , so wird gemafi Block 36 
der Strategiemanager aufgerufen, urn das Ereignis E als Nachricht 
von einem anderen Koordinations-Server zu verarbeiten, wie 
nachstehend anhand der Fig. 33 noch naher erlautert werden wird. 

Nach alien drei Schritten 34, 35 bzw. 36 wird in der 
Programm-Hauptschleif e gemaS Fig. 3 anschlieSend zum Block 27 
zuruckgekehrt , urn den selben Zyklus hinsichtlich eines nachsten 
unabhangigen Prozesses P zu durchlaufen. 

Wie aus Fig. 4 ersichtlich ist, wird im Unterprogramm, Block 

35 in Fig. 3, einleitend im Schritt 37 der Request (Ereignis E in 
Fig. 3) als lokaler Request R def iniert . Bei 3 8 wird sodann 
abgefragt, ob der Request R eine giiltige Anf rage eines 
Koordina t ions - Servers ist. Falls nein, wird im Schritt 39 eine 
Fehlermeldung erzeugt, und es wird sofort zum Ende dieses Unter- 
programms 3 5 iibergegangen . Falls R jedoch eine giiltige Anf rage 
ist, wird gemaS Block 4 0 {s. auch nachstehende Erlauterung zu 
Fig. 5) zu einem Unterprogramm betreffend Anlegen und Inspizieren 
von Kommunikationsobj ekten iibergegangen; weiters folgt ein 
Unterprogramm, Block 41 (s. auch Fig. 9), betreffend Transakti- 
onskontrolle , sodann ein Unterprogramm, Block 42, betreffend 
transaktionale Befehle (s. Fig. 13) und schlieSlich im Block 43 
ein Unterprogramm " Prozefi-Bef ehl " (s. auch nachstehende 
Erlauterung zu Fig. 24. Mit diesen Teilen 40 bis 43 wird somit 
die Art des jeweiligen lokalen Request R untersucht, und es 
werden die gewiinschten Vorgange bewirkt . 

Nachstehend werden anhand der Fig. 5 bis 4 0 die zum Teil 
bereits allgemein angesprochenen, zum Teil noch nicht erwahnten 
Befehle bzw. Funktionen naher erlautert, wobei ganz allgemein, 
wie bereits auch aus den Fig. 3 und 4 zu erkennen war, fur die 
Darstellung in den Zeichnungsf iguren gilt, daE mit starkeren 
Linien dargestellte Blocke auf in der Folge zu erlauternde 
Figuren verwiesen wird, die entsprechende Blocke mit starker 
Umrandung, zwecks Verdeut lichung des Zusammenhangs , zeigen. 

Die nachfolgend unter Bezugnahme auf die Fig. 5 bis 4 0 
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beschriebenen Befehle konnen als Erweiterung einer traditio- 
nellen Sprache zu einer "Koordinations " sprache (im Wege einer 
Bibliothekserweiterung oder einer Einbettung in die jeweilige 
Programmiersprache ) angesehen werden. Die hier angegebenen 
Bezeichnungen der Befehle sind aber selbstverstandlich beliebig 
und nur als Beispiele zu verstehen. Die verwendete Beschreibung 
stiitzt sich im allgemeinen auf eine Programmiersprachen-neutrale 
Syntax und ist unabhangig von den Datentypen der jeweiligen 
" Gas t " sprache . Die Durchfiihrung der Befehle erfolgt in den 
Koordinations-Servern oder Agenten; die als bloSe Beispiele 
angegebenen Bef ehlsbezeichnungen (wie " cobj_create" etc.) 
gehoren zur Anwender-Schnittstelle, wobei damit die Bedeutung 
der Erweiterung der Programmiersprachen (Pj_ wird zu Pj_ & Co) 
erkennbar wird. 

Als erstes wird nun der allgemeine Ablauf beim Befehl zum 
Anlegen und Inspizieren von Kommunikationsobj ekten, Block 4 0 in 
Fig. 4, anhand der Fig. 5 naher erlautert . Dabei wird in ver- 
schiedenen Abfragen die Art des lokalen Requests R eruiert, und 
abhangig davon werden unterschiedliche , im folgenden anhand der 
Fig. 6, 7 und 8 naher erlauterte Funktionen im Zusammenhang mit 
Ob j ekten bewirkt . 

Im einzelnen wird einleitend bei 44 abgefragt, ob der lokale 
Request R ein Request zum Anlegen eines neuen Objekts ist. Wenn 
ja, wird zum Block 45 "Ob jektanlegen" (s. Fig. 6) ubergegangen. 
Wenn nein, wird als nachstes abgefragt, ob der eingelangte 
lokale Request ein Request zum "Objektlesen" ist (Abfrage 46) . 
Wenn ja, wird im Block 4 7 (s. Fig. 7) der Befehl "Lesen eines 
Objekts" ausgefiihrt. Wenn nein, wird als dritte Abfrage bei 4 8 
gepruft, ob der lokale Request R ein Request zum alternativen 
Warten (Uberwachung von Objekten) ist. Wenn ja, wird das Unter- 
programm alternatives Warten, Block 4 9 (s. Fig. 8) aufgerufen; 
wenn nein, wird im Ablauf gemafi Fig. 4 zum Block 41 ubergegangen. 

Es folgt nun eine Erlauterung der vorstehend angesprochenen 
Funktionen, wobei nur fur jene, die an die Anwender- 
Schnittstelle exportiert werden, Namensbeispiele angegeben 
werden . 

- Anleaen eines Objekts: OID <- cobj__create (Typ, Strategie) 

(s. Fig. 6) 

Diese Funktion dient dazu, ein neues Kommunikationsobj ekt 
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anzulegen, wobei als Antwort eine eindeutige Objektidentif i - 
kationsnummer (OID) fur das neue Objekt retourniert wird. 
Diese OID wird an andere Befehle als Argument weiterge- 
reicht. Gewiinschtenf alls kann beim Anlegen des neuen Objekts 
- als sog. Option - eine Verteilungsstrategie selektiert 
werden, "default "ma£ig (d.h. vom System vorgeschlagen) wird 
eine Standardstrategie verwendet . Der beim Anlegen 
definierte Typ spezif iziert , ob es sich um ein nur einmal 
beschreibbares Objekt (write-once-Objekt ) oder um ein 
aktualisierbares Objekt ( "up-dateble" -Objekt) handelt . 
Weiters wird, wie aus Fig. 6, Block 45, ersichtlich ist, eine 
neue Obj ektstruktur angelegt, die vom lokalen Agenten 
verwaltet wird, die durch die OID eindeutig gekennzeichnet 
ist, und die ein neues Kommunikationsobjekt darstellt. Der 
Objektstatus ist zunachst nicht definiert ("UNDEFINED"), und 
es wird eine Objektzeitmarke definiert (und gleich Null 
gesetzt) . 

- Lesen eines Obiekts: Value <- cobj_read (BlockingFlag, OID) 

. (s . Fig. 7) 

Diese Funktion wird fur nicht aktualisierbare Kommuni- 
kationsobj ekte verwendet und retourniert den Inhalt des 
gewiinschten Kommunikationsobjekts , falls dieses bereits 
definiert ist (d.h. in einer Transaktion geschrieben wurde) . 
Falls das Kommunikationsobjekt noch undefiniert ist und ein 
blockierendes Kennzeichen-Bit , das BlockingFlag, gesetzt 
ist, wartet der Befehl, bis das Objekt beschrieben wird, 
ansonst retourniert er eine Fehlermeldung . 

Auch falls der ProzeS nicht berechtigt ist, auf das Objekt 
OID zuzugreifen, erfolgt eine Fehlermeldung. 

Falls jedoch das Objekt definiert und zugreifbar ist, wird 
sein Wert retourniert; ansonst wird, falls das Kennzeichen 
"BlockingFlag" gesetzt ist, die Lese-Anf rage an das Objekt 
angehangt , wo sie automatisch aufgeweckt wird, sobald das 
Objekt beschrieben wird. 

Es hangt von der jeweiligen Verteilungsstrategie und ihren 
Flags ab, ob es bei einer Leseanf orderung ausreicht, die 
lokale Obj ektstruktur zu testen, oder ob Kommunikations - 
schritte durchgefiihrt werden mussen, die andere Agenten nach 
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dem Zustand und Wert des Objekts befragen. 

Im einzelnen wird beim "Objekt-Lesen" gema£ Fig. 7 einleitend 
bei 50 abgefragt, ob der ProzeS auf das Objekt zugreifen 
darf, und ob das Objekt von write-once-Typ ist . Wenn das Ab- 
f rageergebnis negativ ist, erfolgt bei 51 eine Fehlermel- 
dung, wenn das Ergebnis jedoch posit iv ist, dann wird bei 52 
abgefragt, ob der Objektstatus definiert ist. Wenn ja, wird 
bei 53 der Wert des Objekts retourniert, und es wird zum 
Ende der Funktion (bzw. Block 41 in Fig. 5) weitergegangen. 
Wenn jedoch der Objektstatus nicht definiert ist, wird bei 
54 abgefragt, ob blockierend gelesen wird (d.h. ob das 
BlockingFlag gesetzt ist) , und wenn nein, erfolgt bei 55 
eine Fehlermeldung; wenn ja, wird im Schritt 5 6 weiters 
abgefragt, ob der Request vom Benutzer aufgerufen wurde, was 
bedeutet, dafi fur diesen Lese-Request noch keine Lese- 
Request-Struktur existiert. Bei negativem Ergebnis wird zum 
Schritt 41 weitergegangen; bei positivem Abf rageergebnis 
wird jedoch gemaS Block 57 eine Read-Request-Struktur 
angelegt, die dann an das Objekt angehangt wird. Danach wird 
gema£ Block 5 8 der Strategiemanager aufgerufen, urn die 
Funktion, da£ das Objekt gelesen werden soli, auszufuhren. 
Dieser Schritt 58 wird nachstehend anhand der Fig. 34 noch 
naher erlautert werden. 

- Alternatives Warten: FiredOID <- alt_wait (ListOf OIDs) 

(s. Fig. 8) 

Dieser Befehl wird fur nicht aktualisierbare Kommunikations- 
objekte verwendet und wartet wie ein blockierendes Lesen auf 
eine Gruppe von Kommunikationsobjekten . Sobald eines dieser 
Kommunikationsobjekte aus der Liste ListOf OIDs definiert 
ist, retourniert der Befehl die entsprechende OID-Nummer des 
Objekts. Damit kann bequem (und ohne "busy-waiting") eine 
Synchronisation mehrerer Kommunikationsobjekte programmiert 
werden. 

Falls eines der in der Liste (ListOfOIDs) bezeichneten 
Objekte nicht existiert oder nicht vom write-once-Typ ist, 
Oder der ProzeB nicht berechtigt ist, auf eines dieser 
Objekte zuzugreifen (s. Block 59), erfolgt - gemafc Schritt 
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60 - eine Fehlermeldung. 

Fur jede OID aus der Liste ListOfOIDs gilt, da£ - falls das 
durch die OID bezeichnete Objekt definiert ist (Abfrage 61) , 
- dieses Objekt als das "gefeuerte Objekt" retourniert wird 

(bzw. sein Listenindex) , s. Block 62 in Fig. 8. 
Falls kein Objekt aus der ListOfOIDs -Liste definiert ist, 
wird an jedes Objekt (d.h. an seine vom lokalen Agenten - 
21, 22 oder 23 gemaS Fig. 2 - verwaltete Objektstruktur ) aus 
dieser Liste, falls gemaB Abfrage 63 der Request vom 
Benutzer aufgerufen wurde , eine " alt_wait " -Anf rage angehangt 

(Schritte 64 bis 67, Fig. 8). 

Dabei wird bei 64 ein "Alternatives Warten" -Request erzeugt, 
bei 65 wird das nachste Objekt 0 aus der Warteliste 
(ListOfOIDs) definiert, und bei 66 wird abgefragt, ob dieses 
Objekt O leer ist; wenn nein, wird der M alt_wait " -Request an 
das Objekt O angehangt (Schritt 67) . Sodann wird der 
Strategiemanager informiert, da£ das Objekt O gelesen werden 
soil, s. Schritt 58 (der wie erwahnt nachfolgend anhand der 
Fig. 34 noch naher erlautert werden soli). Die Schritte 65 
bis 67 und 58 werden fur alle Objekte der Liste wiederholt . 
Sobald ein Objekt aus der Liste ListOfOIDs definiert (d.h. 
in einer Transaktion geschrieben) wurde, wird automatisch 
diese Anf rage erfullt, die Nummer des Objekts in der Liste 
retourniert und die Anf rage am aktuellen Objekt sowie alle 
Anfragen, die an den anderen Objekten hangen, entfernt. 

Der Ablauf der Transaktionskontrolle ergibt sich allgemein 
aus dem Schema, Block 41, von Fig. 9, wobei der jeweils 
eingelangte Request R nun im Zusammenhang mit eventuell in ihm 
enthaltenen Transaktions-Bef ehlen untersucht wird. Dabei wird 
einleitend bei 6 8 abgefragt, ob eine Top-Level -Transaktion 
gestartet werden soil, und wenn ja, wird dies gemaS Block 6 9 (s. 
nachfolgend Erlauterung zu Fig. 10) durchgef iihrt ; wenn nein, wird 
bei 70 abgefragt, ob eine Unter-Transaktion gestartet werden 
soli, und wenn ja, wird dies gemaS Block 71 (s. Fig. 11) durch- 
gef iihrt; wenn nein, wird bei 72 abgefragt, ob ein schwaches 
Transaktions-Kommit erfolgen soli; wenn ja, wird das schwache 
Transaktions-Kommit gemaS Block 73 (s. Fig. 12, in Verbindung mit 
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Fig. 13) durchgef uhrt ; wenn nein, wird nach einem Transaktions- 
Kommit mit eventuellem Abbruch abgefragt, s. Block 74 in Fig. 9; 
wenn das Ergebnis ja ist, wird das Transaktions-Kommit gemafi 
Block 75 durchgef iihrt , welches ebenfalls, zusammen mit dem 
schwachen Transaktions-Kommit, in Fig. 12 veranschaulicht ist. 
Falls der Request R kein Transaktions-Kommit -Request ist, wird 
als nachstes bei 76 abgefragt, ob ein Abbruch einer Transaktion 
gewiinscht wird, und wenn ja, wird dieser Transakt ions -Abbruch 
gemaS Block 77 (s. auch Fig. 14) durchgef uhrt ; wenn nein, wird 
als nachstes bei 78 abgefragt, ob der Request eine Transaktions- 
Riicknahme betrifft, und wenn ja, wird diese Rucknahme gemaS 
Block 79 (s. auch Fig. 15) durchgef uhrt ; im anderen Fall wird bei 
80 abschliefiend abgefragt, ob der Request eine Rucknahme eines 
transaktionalen Befehls betrifft, und wenn ja, wird bei 81 diese 
Request -Rucknahme durchgefuhrt (s. auch Fig. 16); wenn nein, wird 
ebenso wie nach Durchfuhrung der einzelnen Transakt ions - 
Funktionen 69, 71, 73, 75, 77, 79 oder 81 zum Block 42 in Fig. 4 
weitergegangen, bei dem es sich um die nachstehend anhand der 
Fig. 17 naher erlauterten transaktionalen Befehle handelt. 

Zuvor sollen jedoch noch die einzelnen Transaktions-Bef ehle , 
69, 71, 73, 75, 77, 79 oder 81 anhand der Fig. 10, 11, 12 (mit 
13), 14, 15 und 16 naher erlautert werden. 

- Start einer Top - Leve 1 - Transakt ion : TID <- top_trans_begin 

(s. Fig. 10) 

Mit dieser Funktion wird eine neue Top-Level -Transaktion 
angelegt und ihre eindeutige I dent i f i z i e r ungsnumme r (TID) 
retourniert . Die TID wird als Argument an andere Befehle 
weitergegeben . 

Im einzelnen wird bei dieser Funktion im Schritt 82 eine 
eindeutige TID erzeugt und eine durch diese TID eindeutig 
gekennzeichnete Transaktionsstruktur angelegt, in der 
vermerkt ist, daS es sich um eine Top -Level -Transakt ion 
handelt (d.h. sie besitzt keine Vater-Transaktion) . Der 
Ausfiihrungszustand von TID wird auf gestartet ("STARTED") 
gesetzt. Sodann wird bei 83 abgefragt, ob der Transakt ions - 
Start iiber das Applikations- Interface (API) des lokalen 
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Softwaresystems aufgerufen wurde ; wenn ja, wird der 
Transaktions-Typ als normal definiert (Schritt 84); wenn 
nein, wird der Transaktions-Typ als Hilf stransakt ion 
festgelegt (Schritt 85) . In beiden Fallen wird anschliefcend 
die TID retourniert (Schritt 86) . 

- Start einer (Unter- ) Transaktion : (TID, MsgNr) <- trans_ 
begin (TID vater ) (s. Fig. 11) 
Diese Funktion, Block 71 in Fig. 11, dient dazu, eine neue 
geschachtelte Untertransaktion anzulegen; retourniert wird 
ihre TID sowie eine eindeutige Kennzeichnung dieses Unter- 
transaktions-Bef ehls . (Genaugenommen ist trans_begin auch 
ein transaktionaler Befehl.) Das Argument TID vater muS eine 
gultige TID enthalten, in der diese Transaktion als Unter- 
transaktion gestartet wird, und dies wird bei 87 einleitend 
abgefragt. TID vater ist abhangig vom Erfolg von TID und 
umgekehrt mu£ TID abgebrochen werden, wenn TID vater nicht 
gutgeht . Da die Isolationseigenschaf t von Transaktionen 
aufgelost wurde, kann TID kommitten, bevor TID vater fertig 
ist. Sollte jedoch TID vater danach f ehlschlagen, wird TID 
kompensiert . 

Im wesentlichen lauft die Prozedur wie bei top_trans_begin 
ab, nur daS in der Transaktionsstruktur vermerkt wird, daS 
TID vater die Vater-Transaktion von TID ist. 

Abgesehen von der Abfrage nach einer TID vater -Transaktion 
wird bei 8 7 auch uberpruft, ob diese TID vater -Transaktion im 
Zustand gestartet ("STARTED") ist, oder ob sie nicht 
gutgegangen ist ("FAILED"). Wenn das Abf rageergebnis bei 87 
negativ ist, wird im Schritt 88 eine Fehlermeldung 
abgegeben. Ansonsten wird im Schritt 89 eine eindeutige TID 
erzeugt, die zugehorige Transaktions-Struktur angelegt, der 
Transaktions-Vater (TID vater ) definiert, der 

Ausfuhrungszustand der Transaktion auf gestartet ("STARTED") 
gesetzt und der Transaktions-Typ als normal definiert. 
Anschliefcend werden bei 90 die TID und die eindeutige 
Nachrichtennummer retourniert, und danach wird - ebenso wie 
im Fall der Fehlermeldung gemaS Schritt 88 - zum Block 42 
(Fig . 4 ) weitergegangen . 
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Schwaches Transaktions-Kommit : Result <- trans_try_ 
commit (TID) 

und 

Transaktions-Kommit : Result <- trans_commit (TID) (s. Fig. 12) 
Beim Start des schwachen Transaktions-Kommits (d.i. eine 
Kommit -Aktion ohne Abbruch) einer Transaktion TID wird 
(ebenso wie beim "starken" oder bedingungslosen Trans- 
aktions-Kommit, bei dem gegebenenf alls ein Abbruch erfolgt) 
die Ausfiihrung aller transakt ionalen Befehle bewirkt, die in 
dieser Transaktion angegeben wurden; wenn nur einer dieser 
Befehle nicht ausfuhrbar ist, kann das Kommit nicht gutge- 
hen, und es wird als Ergebnis hiervon die Nummer des 
f ehlgeschlagenen Befehls retourniert . Ansonst werden, wenn 
das Kommit erfolgreich ist, die Effekte aller Befehle atomar 
sichtbar gemacht und alle spezif izierten Kommit -Aktionen 
angestartet; weiters wird eine Erf olgsmeldung retourniert. 
Wenn die Prozedur fur ein (Schwaches) Transaktions-Kommit 
vom Benutzer aufgerufen wird, dann darf ferner die 
Transakt ions -Ident if ikation TID keine Hilf stransaktion 
^ bezeichnen. 

Im einzelnen wird, wenn die Transaktion, die durch TID 
bezeichnet wird, nicht exist iert, oder wenn ihr Ausfuhrungs- 
zustand nicht " STARTED 11 oder "FAILED" ist, oder wenn der 
Prozefi nicht berechtigt ist, auf die in den transaktionalen 
Anfragen verwendeten Objekte zuzugreifen (s. Abf rage-Block 
91 in Fig. 12), eine Fehlermeldung (Schritt 92 in Fig. 12) 
erzeugt . Uberdies wird der Ausf uhrungszustand der 
Transaktion auf "COMMITTING" gesetzt (s. Block 93). 
Sodann wird - gemaS Block 94 - die Strategie der Transaktion 
aufgrund der in ihr abgesetzten Anfragen bestimmt bzw. uber- 
priift, d.h. die Strategien aller in dieser Transaktion von 
Schreib-Anf ragen geschriebenen Objekte, aller von 
cobj_trans_read (s. unten) gelesenen Objekte, aller Objekte, 
die als PIDs oder in Eintragen in den nachstehend 
erlauterten Anfragen dep_process, compensate_action und 
on_commit_action dienen, sowie die Strategien aller 
Untertransaktionen mussen dieselbe Zuverlassigkeitsklasse 
haben und derselben Basis-Strategie angehoren. Falls dies 
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nicht zutrifft, wird wiederum eine Fehlermeldung erzeugt (s. 
Block 92) . 

Nun wird versucht, jede transakt ionale Anfrage dieser 
Transaction zu erfiillen. Dabei werden gegebenenf alls alle 
transaktionalen Anfragen (Requests) R der Reihe nach in 
einer Schleife 95 mit dem Eingangsschritt 96 (in dem immer 
auf den nachsten Request weitergeschaltet wird) behandelt, 
bis die Liste der Requests abgearbeitet , d.h. leer ist 
(Abfrage 97) , wobei dann auf eine Prozedur "Transakt ions - 
Kommit beenden" (s. Block 98 bzw. Fig. 13) ubergegangen wird. 

Solange noch Requests vorliegen, d.h. R nicht leer ist 
(Abfrage 97), passiert f olgendes : 

-- Wenn es sich bei R um eine Untertransaktion handelt (Abfrage 
99), dann muS die Anfrage terminiert (Abfrage 100) und 
erfolgreich "committed 11 haben (Abfrage 101) ; ansonst wird 
eine Fehlermeldung erzeugt (Block 92). 

-- Wenn die Anfrage R eine Schreib-Anf rage ist (Abfrage 102) , 
so wird sie an die Ob j ektstruktur des zu schreibenden 
Objekts OID angehangt (Block 103) , und es wird versucht, das 
Objekt zu beschreiben (Block 104) ; diese Prozedur wird 
nachstehend anhand der Fig. 23 erlautert werden, hier genugen 
vorerst folgende Erlauterungen : es wird die entsprechende 
Verteilungsstrategie aufgerufen, um eine exklusive Sperre 
auf OID zu bekommen (d.h. die "Hauptkopie " bei Replikations- 
protokollen) ; falls die OID bereits von einer anderen Trans- 
aktion gesperrt ist und die sperrende Transakt ion j linger als 
die vorliegende Transaktion TID ist, muS die jiingere Trans- 
aktion die Sperre temporar fur TID freigeben ( "Deadlock" - 
Vermeidung ! ) ; die Anfrage der jiingeren Transaktionen wird 
automatisch spater wieder auf geweckt ; wenn die OID bereits 
definiert ist und es sich um ein nur einmal beschreibbares 
Objekt handelt, erfolgt eine Fehler-Meldung ; ansonst wird 
das Objekt mit der Nr. OID nun fur TID gesperrt und provi- 
sorisch wird der Wert in OID geschrieben (d.h. er ist noch 
nicht of fiziell sichtbar) ; dabei sind alle bisher in der 
Transaktion TID angemeldeten Schreib-Anf ragen bereits zu 
beriicksichtigen; Kommunikat ionsob j ekte , die in einem uber- 
schriebenen Wert eines aktualisierbaren Objekts vorkommen, 
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werden protokollabhangig der Garbage -Collection (s. Fig. 40) 
unterworfen, sofern ihr Ref erenzzahler 0 geworden ist; 
-- Wenn der Request einen abhangigen ProzeS betrifft (der 
nachfolgend anhand von Fig. 25 noch naher erlautert wird), 
d.h. eine depprocess -Anfrage ist, was mit der Abfrage 105 
in Fig. 12 festgestellt wird, so wird im Schritt 106 ein 
entsprechender dep_process -Request angelegt, der an das PID- 
Objekt des Prozesses angehangt wird, und danach wird dieser 
transaktionale Request wieder im Block 104 (s. Fig. 23) 
behandelt; dabei wird gewartet, bis diese de p_p r o c e s s - 
Anfrage terminiert hat. Falls der Ausf uhrungszustand dieser 
Anfrage nicht "PREPARED" oder "CANCELLED" ist, erfolgt eine 
Fehlermeldung . 

Wenn die Anfrage R eine Anfrage fur transaktionales Lesen 
(s. Fig. 19), d.h. ein cobj_trans_read-Request ist, was bei 
107 in Fig. 12 abgefragt wird, dann wird diese Anfrage (gemaS 
Schritt 10 8) an die Objektstruktur des zu schreibenden 
Objekts OID angehangt, und es wird wieder zur Prozedur gemaS 
Block 104 ubergegangen (s. Fig. 23), wobei dort die 
entsprechende Verteilungsstrategie aufgerufen wird, um eine 
exklusive Sperre auf das Objekt OID zu bekommen (vgl . oben 
den Vorgang bei Schreib-Anf ragen) ; es wird dann getestet, ob 
der gelesene Wert noch immer aktuell ist; falls nicht, oder 
falls bereits anfanglich der trans_cobj_read-Bef ehl 
f ehlgeschlagen hat, erfolgt eine Fehlermeldung. 

Sobald, wie oben beschrieben, alle Anf ragen erfolgreich 
durchgefuhrt wurden (Abfrage R ist leer, Block 97) , wird die 
Prozedur " Transakt ions - Kommit Beenden" Block 9 8 (s. Fig. 13) 
aufgerufen; es darf keine Sperre mehr zugunsten einer 
anderen Transaktion aufgegeben werden; alle Effekte (in 
Objekte geschriebenen Werte) werden nun in einem Schritt 

(atomar) sichtbar gemacht ; dazu gehort auch das Anstarten 
aller "on_commit_action" -Bef ehle dieser Transaktion 

(dieselbe Prozedur wie das Anstarten eines - noch zu 
beschreibenden - unabhangigen Prozesses) und das Schicken 
eines Signals "COMMIT" an alle dep_process - Prozeduren dieser 
Transaktion. Die Zuverlassigkeit der Effekte der Transaktion 
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hangt von der jeweiligen Verteilungsstrategie der 
Transakt ion ab . 

Falls die Transaktion eine Top-Level -Transaktion war, kann 
nun ihre Transaktionsstruktur entfernt werden (was in Fig. 12 
der Einfachheit halber nicht dargestellt ist) . Ansonst wird 
ihr Ausf uhrungszust and auf " COMMITTED" gesetzt, und sie mufi 
aufgehoben werden, bis ihre Vater- Transakt ion terminiert, da 
bis dahin Kompensat ions -Akt ions -Prozeduren noch benotigt 
werden. Wenn es sich um eine Hilf stransaktion handelt, wird 
nun das Beenden (exit) des entsprechenden unabhangigen 
Prozesses auf geweckt . 

Der Aufruf der Verteilungsstrategie, um eine exklusive Sper- 
re zu bekommen , muE nicht sof ort erf olgreich sein, sondern 
kann eine Reihe von Kommunikationsschritten verlangen. 
Sobald eine Entscheidung vorliegt, wird wieder automatisch 
der Transakt ionsmanager aktiviert, um das Kommit (Fig .12) 
f ortzusetzen . 

Eine Fehlermeldung - s. Block 92 in Fig. 12 - bei der Ausfiih- 
rung von transaktionalen Anfragen bedeutet nicht, da£ die 
Transaktion abgebrochen ("aborted") wird; im Falle eines 
schwachen Transaktions-Kommit (Abfrage 109) wird der Ausf uh- 
rungszustand der Transaktion auf "FAILED" gesetzt (Schritt 
110), und die Nachrichtennummer (MsgNr) der Anfrage, die die 
Fehlermeldung verursacht hat, ist abfragbar; diese Anfrage 
kann mit dem Befehl "cancel" zuruckgenommen werden, und es 
kann wiederholt versucht werden, die Transaktion zu 
kommit ten . 

Falls die Strategie der Transaktion eine "zuverlassige" 
Strategie ist, so uberleben die Effekte der Transaktion auch 
Systemf ehler . 

-- Wenn sich bei der Abfrage 109 ergibt, da£ ein " starkes" 
Transaktions-Kommit betroffen ist, so verhalt sich diese 
Funktion trans_commit wie die vorhergehende schwache 
Transakt ions - Kommi t - Funkt ion ( t r ans_t ry_commi t ) mit dem 
Unterschied, da£ dann, wenn das Kommit nicht erf olgreich 
ist, die Transaktion TID automatisch abgebrochen wird, s. 
Block 77 in Fig. 12, "Transakt ions -Abbruch" ( " trans_abort " ) , 
der in Fig. 14 naher veranschaulicht ist. 
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Bevor nun der Abbruch einer Transaktion anhand der Fig .14 
naher erlautert wird, sei noch auf die Prozedur 
" Transakt ions - Kommi t - Beenden " (s. Block 98 in Fig. 12) anhand 
der Fig. 13 eingegangen. 

Bei dieser Prozedur wird einleitend bei 111 abgefragt, ob 
alle transaktionalen Anfragen der Transaktion bereits 
erledigt wurden; wenn nein, wird sofort zum Ausgang dieser 
Prozedur (und beispielsweise zum Block 42 in Fig. 4) 
ubergegangen . Wenn das Abf rageergebnis bei 111 jedoch 
positiv ist, wird bei 112 der Recoverymanager aufgerufen, um 
den atomaren Schritt START durchzuf iihren . Danach wird die 
nachste Anfrage aus der Liste transaktionaler Request der 
Transaktion aufgegriffen (Schritt 113), und bei 114 wird 
abgefragt, ob es noch einen Request R in der Liste R gibt . 
Falls R nicht leer ist, d.h. solange transaktionale Anfragen 
vorhanden sind, wird sodann bei 115 abgefragt, ob der 
Request das Anlegen einer Untertransaktion betrifft; wenn 
ja, wird zum Schritt 113 zuriickgekehrt ; wenn nein, wird 
sodann bei 116 abgefragt, ob ein transaktionaler Befehl 
"Objekt-Schreiben" vom Request betroffen ist. Wenn nein, 
wird bei 117 abgefragt, ob der Request einen unabhangigen 
ProzeS betrifft; falls ja, wird ebenfalls zum Schritt 113 
zuriickgekehrt, andernfalls wird bei 118 abgefragt, ob es 
sich bei dem Request um den transaktionalen Befehl "trans- 
aktionales Objekt-Lesen" handelt; falls nein, wird sodann 
bei 119 abgefragt, ob diese Request den transaktionalen 
Befehl "Kommit-Aktion-Anmelden" betrifft; falls nein, wird 
nun ebenfalls zum Schritt 113 zuriickgekehrt. 
Die transaktionalen Befehle "Objekt-Schreiben", "transak- 
tionales Objekt-Lesen" und "Kommit-Aktion-Anmelden" werden 
nachstehend anhand der Fig. 18, 19 und 21 noch naher 
erlautert werden. 

Wenn im Ablauf gema£ Fig. 13 das Ergebnis der Abf rage nach 
"Objekt-Schreiben" , Block 116, positiv ist, so wird in einem 
Schritt 12 0 der Wert des Objekts vorubergehend in das Objekt 
geschrieben, es wird die Zeitmarke des Objekts inkremen- 
tiert, und der Status des Objekts wird auf "definiert" 
("defined") bzw. "Referenz" ("Reference") gesetzt. Im 
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AnschluS daran wird bei 121 die transakt ionale Prozedur 
"Objekt -Auf wecken" aufgerufen, welche nachstehend anhand der 
Fig. 22 noch naher erlautert werden soil, und es wird danach 
zum Schritt 113 zuriickgekehrt . 

Wenn sich bei der Abfrage 118 ergibt, dafi der Request ein 
transaktionales Objekt-Lesen betrifft, so wird im Schritt 
122 abgefragt, ob die Zeitmarke des betroffenen Objekts 
gleich der Zeitmarke zum Zeitpunkt des Lesens ist, und falls 
dies zutrifft, wird ebenfalls die Prozedur 121 "Objekt- 
Auf wecken" aufgerufen. Wenn dies hingegen nicht der Fall 
ist, dann wird bei 123 der Recovery-manager aufgerufen, urn 
den atomaren Schritt ABBRUCH durchzuf iihren, wonach bei 124 
abgefragt wird, ob das betroffene Kommit ein schwaches oder 
ein normales (starkes) Transakt ions -Kommit war. Im Falle 
eines starken Transakt ions- Kommit s erfolgt dann gemafi Block 
77 der Abbruch der Transaktion, im Fall eines schwachen 
Transaktions-Kommits wird hingegen der Ausf uhrungszustand 
der Transaktion auf "Fehlgeschlagen" ("FAILED") gesetzt, s. 
Block 125 in Fig. 13. In beiden Fallen folgt anschlieSend 
gemaS Schritt 126 eine Fehlermeldung . 

Wenn sich bei der Abfrage 119 ergibt, da£ der Request R das 
Anmelden einer Kommit-Aktion betrifft, so wird gemafi Block 
127 der ProzeSmanager aufgerufen, urn einen unabhangigen 
Prozefi (wie nachfolgend anhand von Fig. 26 erlautert werden 
soil) fur die Kommit-Aktion anzustarten. Im AnschluS daran 
wird ebenfalls zum Schritt 113 zuruckgekehrt . 
Falls bei der Abfrage 114 festgestellt wird, dafi keine 
Requests mehr vorliegen (R ist leer) , wird die zuvor 
vorgenommene exklusive Sperre an alien von der Transaktion 
gesperrten Objekten freigegeben, s. Schritt 12 8, und es wird 
ein Kommit -Signal an alle abhangigen Unter-Prozesse der 
Transaktion gesandt, Schritt 129, wonach im Schritt 130 der 
Ausf uhrungszustand der Transaktion auf " COMMITTED " gesetzt 
wird. Nach dieser erf olgreichen Vollzugsmeldung der Trans- 
aktion wird abschlieSend der Recoverymanager fur die Durch- 
fuhrung des atomaren Schritts "ENDE" aufgerufen (Block 131) . 
Danach wird beispielsweise zur nachsten Prozedur (Trans- 
aktionale Befehle gemaE Block 42 in Fig. 4) ubergegangen . 
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Im Ablauf gemafi Fig. 9 ist nach dem Transakt ions - Kommi t als 
nachste Moglichkeit wie erwahnt ein Transakt ions -Abbruch 
vorgesehen, s. Block 77, und ein solcher Transaktions- 
Abbruch ist auch am Ende der Prozedur gemafi Fig. 12 
( Transakt ions- Kommi t ) vorzunehmen . 

- Abbruch einer Transaktion: trans_abort (TID) (s. Fig. 14) 

Diese Funktion verursacht den Abbruch der angegebenen Trans- 
aktion TID und - falls diese Transaktion Untertransaktionen 
besitzt - rekursiv auch deren Abbruch (s. Block 77' in 
Fig. 14) . Es ist zu beachten, da& dann, wenn eine oder 
mehrere Untertransaktion (en) bereits erfolgreich kommittet 
hat bzw. haben, ein Abbruch der Transaktion die Ausfuhrung 
der Kompensationsaktion (en) von solchen Untertransaktionen 
bewirkt, von der/denen angenommen wird, dafi sie auch alle 
Effekte ihrer Untertransaktionen kompensiert/en, d.h. in 
diesem Fall wird nicht mehr rekursiv abgebrochen. Wenn die 
abzubrechende Transaktion TID eine Vatertransaktion besitzt, 
so kann diese nicht mehr erfolgreich kommi t ten, auSer die 
Transaktion TID wird noch ausdriicklich zuruckgenommen (mit 
Hilfe von "trans- cancel (TID) " , s. unten) . 
Im einzelnen ist der Ablauf gemaS Fig. 14 wie f olgt : 
Nach einem einleitenden Aufruf des Recoverymanagers bei 132, 
urn den atomaren Schritt START auszufiihren, wird bei 13 3 ab- 
gefragt, ob der Ausgangszustand der Transaktion TID "FAILED" 
oder "STARTED" ist; wenn ja, dann wird " trans_ abort " auch 
fur alle Untertransaktionen dieser Transaktion TID aufge- 
rufen, und das Signal "ABORT" wird an alle abhangigen 
( "dep_process" - ) Prozesse (s. unten), die in der Transaktion 
TID gestartet wurden, gesendet . Dabei wird gemaS Schritt 134 
der nachste abhangige ProzeS der Transaktion mit R 
bezeichnet, und bei 13 5 wird abgefragt, ob noch derartige 
Prozesse vorliegen; wenn R noch nicht leer ist, wird gemafi 
Block 219 der Prozefcmanager aufgerufen, urn ein Signal 
"ABORT" an die PID des Requests zu schicken (zu "Signal 
schicken" s. auch nachstehend zu Fig. 27); wenn gemaS Abfrage 
135 keine Prozesse mehr vorliegen, d.h. wenn R ist leer ist, 
dann wird im Schritt 136 die nachste Untertransaktion der 
Transaktion mit T bezeichnet und bei 137 abgefragt, ob es 
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noch eine gab. Wenn ja, wird diese Untertransaktion T gemafi 
Block 77' abgebrochen, und es wird zum Schritt 136 zuriick- 
gekehrt . Sobald keine Untertransaktionen mehr vorliegen 

(Ausgang J der Abfrage 13 7) , wird gemafi Schritt 13 8 der 
Ausgangszustand der Transaktion TID auf " abgebrochen " 

( "ABORTED " ) gesetzt . 

Wenn sich nach einem negativen Abf rageergebnis bei 133 in 
einer Abfrage 13 9 der Ausgangszustand der Transaktion TID 
als " COMMITTED" ergibt, dann werden gemafi Schritt 14 0 

(Definition von nachstem R) ; Abfrage 141 ("Liste R leer ?") 
und Block 142 (Start eines unabhangigen Prozesses) alle 
Kompensationsaktionen dieser Transaktion TID aktiviert 

(dieselbe Prozedur wie das Anstarten eines unabhangigen (= 
INDEP- ) Prozesses) . 

Wenn andererseits der Ausgangszustand der Transaktion TID 
nicht "COMMITTED" (Block 139) , jedoch gemaS Abfrage 143 
"COMMITTING" ist, dann sind alle transaktionalen Anfragen 
der Transaktion aufzufinden, die von der Kommit-Aktion an 
Objekte gehangt wurden, und dort zu entfernen. Auch sind 
mogliche durch die Transaktion TID verursachte Objektsperren 
zuruckzusetzen (Schritt 144). Sodann wird die Prozedur 
"Objekt-Aufwecken" 121 (s. Fig. 22) aufgerufen, um alle von 
der Transaktion gesperrten Objekte aufzuwecken. Sodann wird 
der Zustand der Transaktion auf "abgebrochen" ("ABORTED") 
gesetzt, und die Transaktionsstruktur kann nun entfernt 
werden (Schritt 138). GemaJS Schritt 121 wird anschliefiend 
wieder die Prozedur "Objekt-Aufwecken" aufgerufen (Fig. 22), 
urn die PID des Prozesses der Transaktion aufzuwecken. Danach 
wird bei 14 5 der Recoverymanager aufgerufen, um den Atomaren 
Schritt ENDE auszufuhren. Zu diesem Schritt 145 gelangt man 
auch, wenn bei der Abfrage 143 festgestellt wurde, da£ der 
Zustand der Transaktion nicht "COMMITTING" ist , 

Riicknahme einer Transaktion: trans_cancel (TID) (s. Fig. 15 
bzw. Block 79 in Fig. 9) 
Dieser Request verhalt sich wie " Transakt ions - Abbruch " 
( "trans -abort (TID) " ) , (s. oben bzw. Block 77 in Fig. 14) mit 
dem Unterschied, daS der Erfolg einer umschliefienden Vater- 
transaktion davon nicht betroffen ist. Wenn also nach dem 
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START-Schritt 146 bei der Abfrage 147 festgestellt wird, da£ 
die betroffene Transaktion TID keine Top-Level-Transaktion 
ist, dann wird gemaS Schritt 148 die trans_begin (TID vater ) - 
Anfrage aus der Liste der transaktionalen Anfragen ihrer 
Vater-Transaktion entfernt. Danach - oder wenn die Trans- 
aktion eine Top-Level-Transaktion ist (Abfrage 147) - folgt 
die Abbruch-Transaktion, Block 77, gefolgt vom Beendigungs- 
schritt 149. 

- Rucknahme eines transaktionalen Bef ehls ; cancel (TID, MsgNr) 

(Block 81 in Fig. 9, s. Fig. 16) 
Der letzte Block im Ablauf von Fig. 9 betrifft eine etwaige 
Requestrucknahme (Block 81), wobei in diesem Fall, gemaS 
Fig. 16, einleitend bei 150 nach dem Zustand der Transaktion 
abgefragt wird; sofern dieser Zustand STARTED oder FAILED 
ist, wird der Request mit der angegebenen Nummer von der 
Transaktion TID entfernt, s. Schritt 151 in Fig. 16. Sofern 
der Zustand der Transaktion nicht STARTED oder FAILED ist, 
wird gemaS Schritt 152 eine Fehlermeldung abgegeben. 

Es wird somit gemaS Fig. 16 der durch die Nachrichten-Nummer 
"MsgNr" spezif izierte transaktionale Befehl bzw. Request 
zuruckgenommen. (Betrifft dieser Befehl das Anlegen einer 
Untertransaktion, so hat "cancel" denselben Effekt wie 
" trans_cancel " , s. oben, und analog fur abhangige Prozesse 
denselben Effekt wie " signal_ (CANCEL) " , s. unten; dies ist 
jedoch der Einfachheit halber in Fig. 16 weggelassen worden.) 

Wenn nun wieder zu Fig. 4 zuruckgekehrt wird, so ergibt sich 
aus dem dortigen Ablauf im Anschlu£ an Block 41, Befehl zur 
Transaktionskontrolle , der Block 42: Transaktionaler Befehl. Der 
Ablauf dieser Funktion 42 ist in Fig. 17 naher veranschaulicht , 
wobei ersichtlich ist, daS einleitend abgefragt wird (bei 153), 
ob es sich um einen Befehl zum Objekt-Schreiben handelt . Wenn 
ja, wird die Prozedur "Objekt-Schreiben" gemaS Block 154 
aufgerufen, wobei dieser transaktionale Befehl Objekt-Schreiben 
nachfolgend anhand der Fig. 18 naher erlautert werden soli. 

Wenn kein Befehl zum Beschreiben eines Objekts vorliegt, 
wird anschliefiend bei 155 abgefragt, ob ein Befehl zum trans- 
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aktionalen Lesen vorliegt. Wenn ja, wird gemaS Block 156 die 
Prozedur " transaktionales Obj ekt-Lesen" aufgerufen, die nachfol- 
gend anhand der Fig. 19 beschrieben werden wird. Wenn nein, wird 
als nachstes bei 157 abgefragt, ob der Request einen abhangigen 
ProzeE betrif f t . Wenn ja, wird bei 158 der ProzeSmanager aufge- 
rufen, urn den abhangigen Prozefi anzustarten; die entsprechende 
Prozedur ( 11 depjrocess -START" ) wird nachfolgend im Rahmen des 
ProzeEmanagers noch naher erlautert werden. 

Wenn kein abhangiger ProzeS zu behandeln ist, wird im 
Schritt 159 abgefragt, ob der Request das Anmelden einer 
Kompensations-Aktion betrif ft, und wenn ja, folgt gema£ Block 
160 die Prozedur "Kompensations-Aktion Anmelden" (welche 
nachfolgend anhand der Fig. 20 naher erlautert werden wird). Wenn 
nein, wird schlieSlich bei 161 abgefragt, ob der Request das 
Anmelden einer Kommit-Aktion betrif ft, und wenn ja, folgt geraafi 
Block 162 die nachfolgend anhand der Fig. 21 zu erlauternde 
Prozedur "Kommit -Aktion-Anmelden" . 

Im einzelnen sind die vorstehend bereits angesprochenen 
transaktionalen -Befehle (s. Fig. 17) noch f olgendermaSen zu 
erlautern . 

- Anmelden des Beschreibens eines Obiekts: MsgNr <- 

cobj_write (TID, OID, Value) (s. Block 154 in 
Fig. 17; Fig. 18) 

Mit diesem Befehl wird innerhalb einer Transaktion TID das 
Schreiben eines Wertes ("Value") - s. Block 163 in Fig. 18 - 
in ein Kommunikationsobjekt OID angemeldet. Das Schreiben 
wird aber erst beim erf olgreichen Transakt ions -Kommit 
ausgefuhrt (s. vorstehende Ausfuhrungen zu Fig. 12 und 13) . 
Retourniert wird gemaS Schritt 164 eine lokal eindeutige 
Nachrichten-Nummer ("MsgNr"), mit der man sich im folgenden, 
z.B. zum Rucksetzen, auf diesen Schreibebef ehl beziehen 
kann . 

Es wird im einzelnen mit diesem Befehl eine transaktionale 
Anf ragestruktur generiert, die besagt, da£ der Wert 
("Value") in das Kommunikationsobjekt OID geschrieben werden 
soil, und diese Anf ragestruktur an die durch TID 
gekennzeichnete Transakt ionsstruktur angehangt . 
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Transakt ionales Obi ekt - Lesen : (Value, Time2, MsgNr) <- 

trans_cobj_read (BlockingFlag, OID, TID, Timel) 
(s. Block 156 in Fig. 17; Fig. 19) 
Dieser Befehl wird fur aktualisierbare Komrnunikationsobj ekte 
verwendet und verhalt sich ahnlich wie "Obj ekt -Lesen" 
( "cobj__read" ; s. oben zu Fig. 7), wobei mit einer logischen 
Zeitmarke ("Timel") sichergestellt wird, daS der zu lesende 
Wert neuer als diese Zeitmarke sein muS. Andernfalls wird, 
abhangig vom BlockingFlag, entweder eine Fehlermeldung 
retourniert Oder blockiert. 

Es kann (im Unterschied zu 11 Obj ekt- Lesen" ) in dem Fall, da£ 
ein BlockingFlag gesetzt ist, gewartet werden, bis die Zeit- 
bedingung erfiillt ist, wobei dann neben einer lokal eindeu- 
tigen Kennung des Lesebefehls (= MsgNr) auch der aktuelle 
Wert von OID ("Value") sowie eine logische Zeitmarke 
("Time2") des gelesenen Werts retourniert wird. Wenn ein 
BlockingFlag nicht gesetzt ist und die Zeitbedingung erfiillt 
ist, dann werden dieselben Daten wie beschrieben retour- 
niert, ansonst kommt es zu einer Fehlermeldung, und es wird 
vermerkt, daS das Lesen nicht gutgegangen ist. 
Die Transaktion TID priift nach einem erf olgreichen Lesen 
beim Transaktions-Kommit , ob die Zeitmarke Time2 noch immer 
dem aktuellen Wert des Objekts entspricht, und macht den 
Erfolg des Kommits davon abhangig. 

Die den Lesebefehl eindeutig identif izierende Nummer 
("MsgNr") kann spater zum Riicksetzen des Befehls verwendet 
werden. Analog zu "alt_wait" (s. Fig. 8) gibt es auch einen 
transaktionalen Befehl fur aktualisierbare Kommunikations- 
objekte, der ebenfalls Zeitmarken verwendet. 

Im einzelnen wird gemaS Fig. 19 beim Transaktionalen Objekt- 
Lesen einleitend abgefragt (Schritt 165) , ob der Lese- 
Request bereits beantwortet wurde ; wenn ja, wird sofort zum 
Ausgang (z.B. zu 43 oder 215) der Prozedur 156 iibergegangen; 
wenn nein, wird nachfolgend bei 166 abgefragt, ob eine 
Berechtigung fur den ProzeS gegeben ist, auf das Obj ekt 
zuzugreif en; falls dies nicht zutrifft, wird gemaS Schritt 
167 eine Fehlermeldung abgegeben, und es wird ebenfalls zum 
Ausgang der Prozedur 15 6 iibergegangen. Wenn die Berechtigung 
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jedoch gegeben ist, wird sodann abgefragt, ob der Request 
vom Benutzer aufgerufen wurde (was bedeutet, dafi noch keine 
transaktionale Lese-Request-Struktur an der Transaktion fur 
diese Leseanf orderung existiert) . Wenn der Request vom 
Benutzer aufgerufen wurde, so wird anschlieSend im Schritt 

169 der Zustand des Objekts abgefragt, d.h. es wird 
abgefragt, ob der Zustand "def iniert " ("DEFINED") ist, und 
weiters wird abgefragt, ob die Objekt-Zeitmarke alter, d.h. 
groSer, ist als die Wert-Zeitmarke (Timel) . Wenn sich jedoch 
bei der Abfrage 168 ergibt, da£ noch keine transaktionale 
Lese-Request-Struktur existiert , wird eine solche im Schritt 

170 erzeugt und an die Transaktion angehangt , worauf 
ebenfalls zur Abfrage 169 ubergegangen wird. 

Wenn sodann das Ergebnis der Abfrage 169 positiv ist, wird 
gemaS Schritt 171 die Zeitmarke Time2 des Lesezeitpunkts am 
Objekt vermerkt, und es werden weiters der Wert ("Value"), 
die bereits erwahnte eindeutige Nachrichtennummer (MsgNr) 
und die Wert-Zeitmarke Time2 retourniert . Danach wird zum 
Ausgang der Prozedur 156 iibergegangen . 

Ist hingegen das Ergebnis der Abfrage bei 16 9 negativ, so 
wird bei 172 weiter abgefragt, ob blockierend gelesen wird 
(d.h. ob das vorerwahnte BlockingFlag gesetzt ist) , und wenn 
nein, erfolgt gemaS Schritt 167 eine Fehlermeldung; wenn 
jedoch ja, wird der Strategiemanager aufgerufen, urn die 
Prozedur "Objekt soil gelesen werden", Block 58 (s. auch 
Fig . 3 4 ) durchzuf iihren . 

- DEP-ProzeS-Start : Generieren einer lokalen Prozefistruktur 

(s. Block 158 in Fig. 17): MsgNr <-dep_process (TID, 
PID, LSYS, Site, Entry) (s. Fig. 25) 
Diese Prozedur ist eigentlich dem Prozefimanager zuzuordnen, 
wenngleich sie auch als Transaktionaler Befehl behandelt 
werden kann (s. Fig. 17) und demgemafc hier in der 
Beschreibung vorgezogen werden soli. 

Ganz allgemein wird nach Uberprufung von TID, PID, Entry und 
Site wie bei " indep_process " (s. unten bzw. Fig. 26) eine 
neue ProzeSstruktur erzeugt, falls der Prozefi (mit der 
Nummer PID) auf dem lokalen Rechner (= "Site") laufen soil, 
und der Prozefi wird lokal angestartet, ansonst wird die 
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Verteilungsstrategie von PID aufgerufen, urn den ProzeS an 
den mit "Site" spezif izierten Rechner zu schicken. 
Weiters wird eine transaktionale Anf ragestruktur generiert, 
die besagt, da£ ein abhangiger Prozefi gestartet wurde, und 
diese transaktionale Anf ragestruktur wird an die durch TID 
gekennzeichnete Transaktionsstruktur angehangt. Eine lokal 
eindeutige Nummer wird retourniert, die zum Rucknehmen des 
Befehls verwendet werden kann. 

Eine Transaktion TID kann nur dann erfolgreich kommitten, 
wenn alle ihre abhangigen Unterprozesse erfolgreich 
terminiert haben. 

Eine Hilf stransaktion wird generiert, die als die Transakti- 
on dieses Prozesses in seiner ProzeSstruktur vermerkt wird. 
Im einzelnen wird gemafi dem Ablauf von Fig. 25 einleitend bei 
173 abgefragt, ob der ProzeS auf alle Objekte des abhangigen 
Prozesses sowie auf den Prozefiidentif izierer PID zugreifen 
darf ; wenn nein, erfolgt gemafi Schritt 174 eine Fehler- 
meldung, und es wird zum Ausgang der Prozedur (etwa zu 43) 
ubergegangen . Wenn die Zugrif f sberechtigung gegeben ist, 
wird im Schritt 175 ein dep_process -Request generiert und an 
die Transaktion angehangt, wonach bei 176 die Prozedur 
"ProzeSkreieren" aufgerufen wird, die nachfolgend anhand von 
Fig. 3 0 noch naher erlautert werden wird. Danach wird im 
Schritt 177 eine eindeutige Nachrichtennummer retourniert. 

- Anmelden einer Kompensations-Aktion : MsgNr <- 

compensate_action (TID, PID, LSYS, Site, Entry) 
(s. Fig. 20 bzw. Block 160 in Fig. 17) 
Vorweg wird hier bei 178 uberpriift, ob der aktuelle ProzeS 
mit der Nummer PID ein Zugrif fsrecht auf alle in "Entry" 
vorkommenden Objekte sowie auf die PID besitzt; falls nicht, 
wird eine Fehlermeldung erzeugt (Schritt 179) . 
Ansonst wird im Schritt 180 eine transaktionale Anfrage- 
struktur generiert, die besagt, da£ eine Kompensationsaktion 
definiert wurde, und diese wird an die durch TID gekenn- 
zeichnete Transaktionsstruktur angehangt. Sodann wird im 
Schritt 181 eine lokal eindeutige Nummer retourniert, die 
zum Rucksetzen des Befehls verwendet werden kann. 
Kompensationsaktionen werden gestartet, wenn die Transaktion 
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TID erfolgreich kommittet hat und dann abgebrochen wird. 

- Kommit-Aktion-Anmelden : MsgNr <- on_commit_action (TID, PID, 

LSYS, Site, Entry) (s. Fig. 21 bzw. Block 162 in 
Fig. 17) 

Im Prinzip ist dieser Befehl im Ablauf ahnlich dem Befehl 
"compensate_action" gemaS Fig. 20, nur dafi die Anfrage- 
struktur besagt, da£ eine Kommit-Aktion angemeldet wurde . So 
wird einleitend im Schritt 182 die Zugrif f sberecht igung des 
Prozesses betreffend die Objekte der Kommit-Aktion sowie 
betreffend die PID abgefragt, und falls keine Zugrif fs- 
berechtigung gegeben ist, wird eine Fehlermeldung gema£ 
Schritt 183 abgesetzt. Ansonsten wird im Schritt 184 ein 
Kommit -Request generiert und an die betreffende Transaktion 
angehangt, wonach im Schritt 185 eine eindeutige 
Nachrichtennummer ("MsgNr") retourniert wird. 
Kommit -Aktionen werden beim "Kommit" von TID gestartet . 

Bevor nun auf die ProzeS-Bef ehle (s. Block 43 in Fig. 4) bzw. 
auf den entsprechenden ProzeSmanager (Fig. 25 bzw. Fig. 26 und 28 
bis 31) naher eingegangen wird, soil noch unter Bezugnahme auf 
Fig. 22 und 23 das Aufwecken eines Objekts (vgl. z.B. Block 121 
oder 121' in Fig. 13 bzw. 14) sowie die Behandlung transaktiona- 
ler Requests (s. Block 104 in Fig. 12) naher erlautert werden. 

- Obi ekt - Auf wecken : (Fig. 22; Block 121) 

Hier wird einleitend im Block 186 R als der nachste Request 
des Objekts definiert, und es wird anschlieSend bei 187 ab- 
gefragt, ob R leer ist; falls nein, wird bei 188 abgefragt, 
ob R das Lesen eines Objekts betrifft; wenn ja, wird die 
Prozedur Objekt-Lesen bei Block 47 aufgerufen, und 
anschlieSend wird zum Schritt 186 zuriickgekehrt. Wenn das 
Abf rageergebnis bei 188 negativ ist, wird bei 189 abgefragt, 
ob R ein alternatives Warten betrifft, und wenn ja, wird die 
entsprechende Prozedur 49 aufgerufen, wonach ebenfalls zum 
Schritt 186 zwecks Prufung des nachsten Requests zuriickge- 
kehrt wird. Wenn R auch nicht ein alternatives Warten be- 
trifft, wird gemaS Block 104 die Behandlung transaktionaler 
Requests durchgefuhrt (s. nachfolgende Erlauterung zu 
Fig. 23), wonach wiederum zum Schritt 186 zuriickgekehrt wird. 
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1st R bei der Abfrage 187 als leer festgestellt worden 
(Ausgang "J")/ so wird bei 190 abgefragt, ob das Objekt eine 
Prozefiidentif ikationsnummer ist, und wenn nein, wird zum 
Ausgang der Prozedur 121 ubergegangen; wenn das Abfrage - 
ergebnis jedoch ja ist, wird gemaS Block 190 1 getestet, ob 
der mit PID bezeichnete ProzeS am Terminieren ist; falls ja, 
wird der Prozefimanager aufgerufen, um ein "Schwaches ProzeS- 
Ende" durchzufuhren, s. Block 191, welcher nachstehend 
anhand der Fig. 28 noch naher beschrieben werden wird. Ist 
das Ergebnis des Tests in Block 190' negativ, so wird zum 
Ausgang der Prozedur 121 ubergegangen. 
Behandluna transaktionaler Requests: (Fig. 23, Block 104) 
Hier erfolgt einleitend bei 192 eine Deref erenzierung des 
Objekts zu 0, und bei 193 wird das Verhaltnis O <> Objekt 
abgefragt, d.h. untersucht, ob 0 ungleich dem Objekt ist. 
Bei einem positiven Abf rageergebnis werden im Schritt 194 
die Transaktionalen Requests vom gegenstandlichen Objekt an 
O verschoben, und es wird gemafc Block 104 ' neuerlich die 
Prozedur 104 zur Behandlung von Transaktionalen Requests - 
hier von O - aufgerufen, wonach zum Ende der Prozedur 
ubergegangen wird. 

Ist das Abf rageergebnis bei 193 hingegen negativ, so wird im 
Schritt 195 R als der nachste abhangige Prozefi-Request von 0 
definiert, und bei 196 wird abgefragt, ob R leer ist. Wenn 
nein, wird bei 197 abgefragt, ob der ProzeS terminiert hat, 
und wenn nein, wird der Strategiemanager hinsichtlich der 
Prozedur "Objekt soil gelesen werden", und zwar entsprechend 
der jeweiligen Prozefiidentif ikationsnummer PID, aufgerufen 
{Block 58) . Hat jedoch der ProzeS bereits terminiert (s. 
Abfrage 197) , so wird im Schritt 198 der Request vom Objekt 
entfernt, und im Schritt 19 9 wird abgefragt, ob der Zustand 
des Requests "bereit" oder " zuriickgenommen" ("PREPARED" oder 
"CANCELLED") ist. Wenn nein, wird im Schritt 2 00 das 
Transakt ions - Kommit abgebrochen, es werden die Requests an 
den Objekten entfernt, und der Ausf uhrungszustand wird als 
"FAILED" (f ehlgeschlagen) definiert, wonach bei 201 eine 
Fehlermeldung abgegeben und zum Ausgang der Prozedur 
ubergegangen wird. Wenn hingegen das Abf rageergebnis bei 199 
positiv war, wird die Prozedur 98 " Transakt ions- Kommit - 
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Beenden" (und zwar hinsichtlich der Transaktion des gerade 
behandelten unabhangigen ProzeS-Requests) aufgerufen, wonach 
zum Schritt 195 zuriickgekehrt wird, um den nachsten 
abhangigen ProzeS-Request zu behandeln. 

Wenn sich bei der Abfrage 196 ergibt, daS R leer ist, d.h. 
da£ keine Anfragen hinsichtlich abhangiger Prozesse mehr 
vorliegen, dann wird im Schritt 202 T als die alteste 
Transaktion aller Requests von 0 definiert, und es wird bei 
2 03 abgefragt, ob der Zustand von O gesperrt ("LOCKED") ist 
und die sperrende Transaktion j linger als T ist oder aber 
nicht im Zustand "COMMITTING" vorliegt. Wenn nein, wird T im 
Schritt 204 nun als die sperrende Transaktion definiert, und 
es wird bei 205 der Strategiemanager aufgerufen, um die 
nachstehend anhand der Fig. 3 6 zu erlauternde Prozedur "ist 
Objekt exklusiv gesperrt" durchzuf uhren . Wenn eine derartige 
exklusive Sperre noch nicht vorliegt, wird weiter der 
Strategiemanager aufgerufen (Schritt 206, s. auch Fig. 35 und 
die nachfolgende Erlauterung) , um eine "exklusive Objekt- 
Sperre" zu besorgen. Danach wird zum Ausgang der Prozedur 
104 iibergegangen. 

Die Strategiemanager-Auf ruf e 205, 206 folgen auch, wenn sich 
bei der Abfrage 203 ein positives Ergebnis ergibt, wobei 
dann zuvor gemaS Schritt 2 07 die Ob j ektsperren aller 
Requests der sperrenden Transaktion zugunsten von T (also 
der altesten Transaktion aller Requests von O) freigegeben 
werden, die Requests wieder an die Objekte gehangt werden, 
wonach gemaS 104" die Prozedur 104 betreffend Behandlung 
Transakt ionaler Requests, und zwar nun hinsichtlich aller 
Requests der ehemals sperrenden Transaktionen, aufgerufen 
wird. Danach wird wie erwahnt bei 205 und eventuell auch 206 
der Strategiemanager zur Erzielung einer exklusiven 
Objektsperre aufgerufen . 

Ist bei der Prozedur 205 festgestellt worden, da£ das Objekt 
bereits exklusiv gesperrt ist, so wird im Schritt 208 R als 
der nachste Transaktionale Obj ekt -Schreib-Request oder 
Transaktionale Objekt-Lese-Request von T an O definiert, und 
es wird der Request R von O entfernt. Danach wird bei 209 
abgefragt, ob R leer ist, und wenn ja, wird zum Ausgang der 
Prozedur iibergegangen; wenn R noch nicht leer ist, wird bei 
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210 abgefragt, ob R das Beschreiben eines Objekts betrifft, 
und wenn ja, wird bei 211 sodann abgefragt, ob das zu 
schreibende Objekt ein nur einmal beschreibbares Objelct ist; 
wenn nein, d.h. wenn das Objekt ein aktualisierbares Objekt 
ist, wird sodann im Schritt 212 der Zustand des Objekts auf 
"gesperrt" ("LOCKED") gesetzt, der gewiinschte Wert wird 
vorubergehend in das Objekt geschrieben, und es wird die 
Zeitmarke erhoht; der Request ist damit erfullt, und es wird 
zum Schritt 208 zuruckgekehrt, um den nachsten Request zu 
behandeln. 

Ist hingegen bei der Abf rage 211 das Ergebnis, dafi das zu 
schreibende Objekt ein write-once -Objekt ist, so wird bei 
213 abgefragt, ob der Zustand des Objekts "def iniert " 
{ "defined") ist, und wenn ja, kommt es zum Abbruch des 
Transaktions-Kommits gemafi Schritt 200 und zur Fehlermeldung 
gemafi Schritt 201. Wenn jedoch der Zustand des Objekts nicht 
"def iniert" ist, d.h. das Abf rageergebnis bei 213 negativ 
ist, dann wird im Schritt 214 abgefragt, ob der Objektstatus 
"gesperrt" ("LOCKED") ist, d.h. ob das betroffene Objekt von 
einem anderen Schreib-Request her gesperrt ist. Wenn ja, 
erfolgt ebenfalls ein Abbruch des Transaktions-Kommits gemafi 
Schritt 200 sowie eine Fehlermeldung gemafi Schritt 201; wenn 
nein, erfolgt der bereits beschriebene Vorgang gemafi 212, 
bevor zum Schritt 2 08 zuruckgekehrt wird. 

Wenn sich bei der Abf rage 210, ob R ein Objekt-Beschreiben- 
Request ist, ein negatives Ergebnis ergibt, wird die 
Prozedur "Transaktionales Objekt-Lesen" gemafi Block 156 
aufgerufen (s. Fig. 19 und zugehorige Beschreibung) , wonach 
bei 215 abgefragt wird, ob die Lese-Anfrage beantwortet 
werden konnte. Wenn nein, wird zum Schritt 208 zuruckge- 
kehrt, und wenn ja, wird der Zustand des Objekts auf 
"gesperrt" ("LOCKED") gestellt, der Request ist erfullt, s. 
Block 216, und es wird ebenfalls zum Schritt 208 
zuruckgekehrt . 



In Fig. 24 ist der Prozefi-Bef ehl -Ablauf (s. Block 43 in 
Fig. 4) naher veranschaulicht . Dabei wird als erstes bei 217 
abgefragt, ob der Request einen unabhangigen Prozefi 
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(indep_j?rocess) betrifft, und wenn ja, wird der bereits vorste- 
hend im Zusammenhang mit Fig. 13 angesprochene Prozefimanager 
betreffend Start eines unabhangigen Prozesses, Block 127, 
aufgerufen. Betrifft der Request jedoch keinen unabhangigen 
ProzeS, so wird bei 218 abgefragt, ob der Request das Senden von 
Signalen betrifft, und wenn ja, wird bei 219 der Prozefimanager 
betreffend Prozedur "Signal-Schicken" (s. nachfolgend zu erlau- 
ternde Fig. 27) aufgerufen. Ansonsten wird bei 220 abgefragt, ob 
der Request ein " Schwaches - ProzeS- Ende " ( "coke_try_exit " ) 
betrifft, d.h. das Beenden eines Prozesses mit Erlaubnis- 
Uberpruf ung; wenn ja, wird bei 191 der ProzeSmanager betreffend 
Durchfiihrung dieses Prozesses "Schwaches ProzeS-Ende" aufge- 
rufen; wenn nein, wird bei 221 abschlieSend abgefragt, ob ein 
unbedingtes Beenden eines Prozesses ( "coke_exit " ) vom Request 
betroffen ist, und wenn ja, wird der Prozefimanager zur Durch- 
fiihrung der Prozedur "Prozefi-Ende" aufgerufen. Die Prozeduren 
"Schwaches ProzeS- Ende " und "Prozefi-Ende" werden nachfolgend 
anhand der Fig. 2 8 und 2 9 naher beschrieben werden. 

Die vorstehend angesprochenen Prozesse sowie weiters die 
bereits fruher erwahnten Prozesse "Prozefi-Kreieren" und "ProzeS- 
Aufspannen" werden nunmehr anhand der Fig\ 26 bis 31 erlautert . 
- Starten eines unabhangigen Prozesses INDEP-Prozefi-Start : 

indep_process (PID, LSYS, Site, Entry) (s. Fig. 26) 
Mit diesem Befehl wird ein unabhangiger (= autonomer) ProzeS 
gestartet, der eindeutig durch eine PID-Nummer (Prozefi- 
identif ikationsnummer ) bezeichnet wird. Diese PID-Nummer ist 
selbst ein Kommunikationsobj ekt , dessen Wert den Ausfuh- 
rungszustand des Prozesses reflektiert. Der ProzeS wird auf 
dem Rechner an der Stelle "Site" (X, Y Oder Z in Fig. 2) auf 
dem lokalen Sof twaresystem LSYS (18, 19 bzw. 20) gestartet, 
wobei zuvor - s. Schritt 223 in Fig. 26 - iiberpruft wird, ob 
der aktuelle ProzeS ein Zugrif f srecht auf alle in "Entry" 
vorkommenden Objekte sowie auf die PID besitzt (sowie auch, 
ob diese Objekte und die PID hinsichtlich der verwendeten 
Strategie kompatibel sind, ob "Site" eine gultige 
Rechneradresse ist, und ob TID eine laufende (STARTED oder 
FAILED) Transaktion bezeichnet) ; falls dies nicht erfullt 
ist, wird gemaB Schritt 224 eine Fehlermeldung erzeugt . 
Falls die PID bereits als solche in Verwendung ist, ergeht 
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ebenfalls eine Fehlermeldung . 

"Entry" spezifiziert die auszuf uhrende Funktion, der als 
Argumente Kommunikationsob jekte mitgegeben werden konnen, 
die dieser neue Prozefi dann auch sehen darf . 

Es wird gemaS Block 176 (s. auch nachstehend zu Fig. 30) eine 
neue Prozefistruktur generiert, falls der ProzeS auf dem 
lokalen Rechner (= "Site") laufen soil, und der ProzeS wird 
lokal angestartet; ansonst wird der Strategiemanager von PID 
aufgerufen, um dem ProzeS an den mit "Site" spezif izierten 
Rechner zu schicken. Die Zuverlassigkeit des Anstartens 
hangt von der jeweiligen Verteilungsstrategie ab. 
Es wird ferner eine Hilf stransaktion generiert, die als die 
Transaktion dieses Prozesses in seiner ProzeSstruktur 
vermerkt wird. 

Wenn ein unabhangiger ProzeS von einer zuverlassigen 
(Protokollf lag "RELIABLE") Verteilungsstrategie ist, wird er 
nach einem Systemf ehler wiederhergestellt , und falls er noch 
nicht terminiert hat, wird er dann auch automatisch wieder 
angestartet. 

Unabhangige Prozesse werden vom Koordinations -Server solange 
gestartet, bis sie einen endgultigen Ausf uhrungszustand 
erreicht haben. 

- Schicken von Sianalen: signal (PID, Signal) (s. Fig. 27) 
Mit diesem Request wird ein spezif iziertes Signal (z.B. 
"ABORT" , "COMMIT" oder "CANCEL" etc.), zu dem noch optional 
Flags spezifiziert werden konnen, die z.B. besagen, ob das 
Signal an Unterprozesse weitergereicht werden soil, an den 
ProzeS gesendet, der durch die PID-Nummer bezeichnet wird. 
Hierbei wird in den aufgerufenen Prozeduren zweckmaSig auch 
uberpruft, ob PID ein Kommunikat ionsob j ekt ist, das einen 
ProzeS bezeichnet, und ob es sich um ein giiltiges Signal 
handelt (z.B. darf ein Benutzer an einen abhangigen ProzeS 
( "dep_process" ) , der bereits "fertig" ("PREPARED") ist, 
nicht mehr ein Signal "Abbruch" ("ABORT") schicken). 
Falls der durch die PID-Nummer bezeichnete ProzeS auf einem 
fremden Rechner lauft (s. Abfrage 225 in Fig. 27), wird der 
Strategiemanager von PID aktiviert, um das Signal an den 
Agenten auf dem fremden Rechner weiterzuleiten (Block 226; 
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Prozedur "Signal-Schicken" ; s. nachfolgend zu Fig. 38), der 
es dort an den entsprechenden ProzeS schicken wird. Die 
Zuverlassigkeit des Weiterleitens hangt von der 
Verteilungsstrategie ab ("RELIABLE" Oder "UNRELIABLE") . 
I in ubrigen werden gemaS Fig. 27 bei 227, 228, 229 bzw. 230 
die jeweiligen Signale auf ihren Gegenstand ("ABORT", 
"COMMIT" , "CANCEL" etc.) abgefragt, und zutref f endenf alls 
wird das zugehorige " ProzeS-Ende" mit dem entsprechenden 
Exit-Wert ("ABORT" bzw. "COMMIT" bzw. "CANCEL"), Block 191, 
aufgerufen, das nachfolgend unter Bezugnahme auf Fig. 2 8 
erlautert wird. 

Beenden eines Prozesses mit Erlaubnis-Uberpriif ung (Schwaches 

ProzeS-Ende) : coke_try_exit (ExitValue) (s. Fig. 28) 
Dieser Befehl dient zum Beenden eines aktuellen Prozesses, 
wobei der "Exit-Wert" ("ExitValue") analoge Werte wie 
Signal -Typen annehmen kann. Der erreichte Ausf uhrungszustand 
wird in die PID geschrieben. 1st der gewiinschte Zustand 
nicht erreichbar, so retourniert "coke_try_exit " eine 
Fehlermeldung . 

Es wird also - nach einem "Atomaren Schritt START" 231 - 
einleitend uberpriift, ob der "Exit-Wert" erlaubt ist 
(Abfrage 232) - das hangt davon ab, ob "coke_try_exit " vom 
Benutzer oder vom System aufgerufen wurde . Letzteres ist 
z.B. der Fall, wenn intern ein Signal "ABORT" oder ein 
Signal "COMMIT" an einen ProzeS geschickt wird. 
Erlaubt ist: "Exit-Wert" - von wem - in ProzeS welchen Typs 
(bei dem der Ausf uhrungszustand entweder noch nicht gesetzt 
ist oder den explizit angegebenen Wert hat) : 
z.B. "PREPARE" von Benutzer in einem unabhangigen oder 
abhangigen ProzeS; 
oder : 

"COMMIT" von Benutzer an INDEP-ProzeS (nicht gesetzt oder 
SUCCEEDED) oder von SYSTEM an DEP-ProzeB (PREPARED) ; 
oder : 

"ABORT" von Benutzer an INDEP-ProzeS (nicht gesetzt oder 
SUCCEEDED) oder an DEP-ProzeS oder von SYSTEM an DEP-Prozefi 
(nicht gesetzt oder PREPARED) ; 
oder : 
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"CANCEL" von Beniitzer an DEP-Proze£ (nicht gesetzt oder 
PREPARED) . 

Danach wird am ProzeS vermerkt, dafi er am Terminieren ist 
(Block 233) . 

Wenn der Exit-Wert "ABORT" ist (s. Abfrage 234 in Fig. 28), 
wird nach Beschreiben der PID (Block 235) die atomare 
"coke_try_exit" -Prozedur wie folgt beendet (im folgenden 
Prozedur A genannt) : alle schlafenden Anfragen an PID sowie 
ein mogliches ProzeEende eines Vaterprozesses werden aufge- 
weckt (Block 121) : nicht mehr benotigte Transaktionsstruk- 
turen von f ehlgeschlagenen Top-Level-Transaktionen dieses 
Prozesses werden nach Uberpriifen, ob ein endgultiger 
ProzeSzustand vorliegt (Schritt 236) , entfernt (Block 237) ; 
die Ref erenzzahler aller Objekte, auf die der terminierende 
ProzeS zugreifen durfte, werden zwecks Garbage-Collection, 
Block 238 (s. auch Fig. 40) (abhangig vom Protokoll der PID 
des Prozesses), dekrementiert ; die ProzeSstruktur wird 
entfernt (Schritt 239) , wonach der Atomare -Schritt ENDE 
(Recoverymanager) folgt (Block 240) . 

Wenn es sich um einen unabhangigen ProzeS ( 11 indep process 11 ) 
handelt (s. Abfrage 241, Ausgang J), wird nach einer Zu- 
standsabf rage bei 242, wenn der Zustand der Hilf stransaktion 
"gestartet " ("STARTED") ist, das schwache Transaktions- 
Kommit " trans_try_commit " von seiner Hilf stransaktion 
aufgerufen (Block 73) . 

Falls der Zustand der Hilf stransaktion "COMMITTED" ist 
(Abfrage 243), wird (falls der Exit-Wert "PREPARE" ist) der 
Ausfuhrungs zustand des Prozesses im Block 23 5 auf 
"SUCCEEDED" gesetzt (hier kann gegebenenf alls auch 
"PREPARED" verwendet werden) , und falls der Exit-Wert 
"COMMIT" ist, wird der Ausfuhrungs zustand des Prozesses auf 
"COMMITTED" gesetzt, und die vorstehend erlauterte Prozedur 
A wird angewendet. Falls bei der Abfrage 243 der Zustand 
nicht "COMMITTED" ist, erfolgt eine Fehlermeldung (Schritt 
244) . 

Wenn es sich um einen abhangigen ProzeS { "dep_process" ) 
handelt (negatives Ergebnis bei der Abfrage 241) , wird: 
- falls der "Exit-Wert" "PREPARE" ist (Abfrage 245) , der 

Ausf iihrungs zustand seiner Hilf stransaktion berechnet (dieser 
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ist noch nicht bestimmbar , wenn eine Untertransaktion oder 
ein abhangiger ProzeS der Hilf stransaktion noch nicht termi- 
niert hat; dies geht in Ordnung, wenn alle Untertransakti - 
onen und jeder abhangige ProzeE gutgegangen sind, sonst 
nicht) ; mit dem schwachen Transakt ions -Kommit wird gewartet 
(s. Abfrage 246), bis sich der Zustand bestimmen laSt ; ist 
dieser nicht in Ordnung, wird eine Fehlermeldung retour- 
niert; ansonst werden alle transaktionalen Anfragen der 
Hilf stransaktion des Prozesses an die Transaktion des abhan- 
gigen Prozesses transferiert (Block 248) ; ist diese Trans- 
aktion nicht lokal (s. Abfrage 247), so muS der Transfer vom 
Strategiemanager (entsprechend der PID des Prozesses) 
durchgefiihrt werden (s. Block 24 9; vgl . auch Fig. 39); erst 
danach wird der Ausgangszustand des Prozesses auf "PREPARED" 
gesetzt (Block 235) , und es folgt die Prozedur A. 
Haben alle Unterprozesse der Hilf stransaktion terminiert (s. 
Abfrage 250) , nachdem ein Kommit der Hilf stransaktion als 
nicht moglich festgestellt wurde (Abfrage 246) , so erfolgt 
eine Fehlermeldung (Schritt 251) ; ansonsten folgt die 
Prozedur A. , 

- falls der "Exit-Wert" nicht "PREPARE" ist (s. Abfrage 245), 
mu£ er "ABORT" sein, d.h. der Ausgangszustand des Prozesses 
wird auf "ABORTED" (Block 235) gesetzt und die Prozedur A 
angewendet . 

Beenden eines Prozesses: coke_exit (ExitValue) (s. Fig. 29) 
Der Ablauf ist hier wie beim "Schwachen ProzeS-Ende" (s. 
oben bzw. Block 191 in Fig. 28), nur daS im Fehlerfall der 
ProzeS (s. Abfrage 252) automatisch abgebrochen wird, d.h. 
es wird automatisch das Signal "ABORT" an den aktuellen 
ProzeE geschickt (Block 219 "Signal-Schicken" , "Abort" an 
ProzeE) . 

ProzeS-Kreieren : create_process (s. Fig. 30) 

Nach einem einleitenden Aufruf des Recoverymanagers 
betreffend "Atomarer Schritt START" bei 253 wird gemafi 
Schritt 254 getestet, ob fur den ProzeS mit der angegebenen 
Nummer bereits eine. Prozefi-Struktur existiert; wenn ja, wird 
sofort zum ProzeS-Ende iibergegangen ; wenn nicht, wird der 
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Strategiernanager aufgerufen, um f estzustellen, ob das Objekt 
exklusiv gesperrt ist, s. Block 205 sowie die nachfolgend zu 
erlauternde Fig. 36. Falls nein, wird der Strategiernanager 
aufgerufen, um gemafi Block 206 (s. auch Fig* 35) eine exklu- 
sive Objekt -Sperre fur den betreffenden Prozefi zu besorgen, 
und es wird zum Schritt 2 05 in Fig. 3 0 zuriickgekehrt , wobei 
dann, da nun das Objekt exklusiv gesperrt ist, in der 
Prozedur weitergegangen und bei 255 abgefragt werden kann, 
ob die angegebene Prozefiidentif ikationsnummer PID bereits 
zur Ident if izierung eines Prozesses in Verwendung ist. 
Sollte dies zutreffen, so wird bei 256 eine Fehlermeldung 
abgegeben, und das Ende des Prozesses ist erreicht. Wenn die 
PID-Nummer noch nicht verwendet wird, wird nun im Schritt 
257 am PID-Objekt vermerkt, dafi es eine PID darstellt, d.h. 
es dient ab nun zur Identif izierung dieses Prozesses. Danach 
wird abhangig davon, ob der ProzeS am lokalen- Rechner durch- 
gefuhrt werden soli (Abfrage 258) , dann, wenn der lokale 
Rechner zustandig ist, die gewunschte neue ProzeS-Struktur 
angelegt, Block 259, und der Transaktionsmanager wird zum 
Start einer Top-Level-Transaktion gemaS Block 69 (s. auch 
Fig. 10) aufgerufen, wonach die neue Transaktion im Schritt 
260 als Hilf stransaktion des betroffenen Prozesses einge- 
tragen wird; danach wird. "ProzeS-Auf spannen" 29 (s. auch 
Fig. 31) aufgerufen; abschlieSend wird der Recoverymanager 
zur Durchfiihrung des "Atomaren Schritts-ENDE" aufgerufen, s. 
Block 261 in Fig. 30. Wenn sich bei der Abfrage 258 ergibt, 
daS der Prozefi nicht am lokalen Rechner durchzuf iihren ist, 
wird der Strategiernanager zur Durchfiihrung der Prozedur 
"Prozefi-Schicken" gemaS Block 262 aufgerufen, wonach eben- 
falls der Ende-Schritt 261 f olgt . Die Prozedur 262 "ProzeS- 
Schicken" wird nachfolgend anhand der Fig. 37 naher 
erlautert . 

ProzeS-Aufspannen : (s. Fig. 31) 

Beim ProzeS-Auf spannen wird abhangig davon, ob das lokale 
Sof twaresystem als voriibergehend oder als permanent auftritt 
(Abfragen 263 - " Sof twaresystem ist X-transient ?", 264 - 
" Sof twaresystem ist transient ?" und 265 - " Sof twaresystem 
ist permanent ?") sowie abhangig davon, ob der lokale Server 
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lauft (Abfragen 266, 267) entweder der lokale Server im 
Schritt 268 angestartet, um gemaE Schritt 269 die Entry- 
Angaben an den Server zu schicken und den ProzeS zu starten, 
oder aber der letztere Vorgang 26 9 wird - im Fall eines 
permanenten lokalen Sof twaresystems , wenn der Server bereits 
lauft, unmittelbar durchgef uhrt . Im Fall eines X-transienten 
lokalen Sof twaresystems (Abfrage 263 ) wird im Falle, da£ 
der Server bereits lauft (s. Abfrage 266), die Triggerung 
der gewunschten Arbeit bewirkt, wenn der Server frei ist, 
und zu diesem Zweck wird in einer Schleife erneut der 
Vorgang 11 Prozefi-Auf spannen" gemaS Block 29' aufgerufen. Im 
Falle daS das lokale Sof twaresystem weder X-transient noch 
transient hoch permanent ist, wird gemaS Schritt 270 eine 
Fehlermeldung abgegeben. 



AbschlieSend soil noch anhand der Fig. 32 bis 40 der 
Strategiemanager erlautert werden, der fur die Festlegung der 
Verteilungsstrategie , auch Kommunikationsprotokoll genannt , 
verantwortlich ist . 

- Befehl ausfuhren: (s. Fig. 32) 

Bei der Ausfuhrung des Befehls konnen Nachrichten an andere 
Koordinations-Server geschickt werden, was von der 
jeweiligen Verteilungsstrategie kontrolliert wird. Im Ablauf 
gemafc Fig. 32 wird nach dem "Atomaren Schritt START" des 
Recoverymanagers bei 271 der Strategiemanager der 
betroffenen Strategie zur Ausfuhrung des Befehl aufgerufen 
(Block 272) , und es wird sodann im Schritt 273 O als das 
nachste Objekt definiert, das in der Bearbeitung vorkam, und 
im Schritt 274 abgefragt, ob O leer ist. Solange O nicht 
leer ist, wird fur den Fall, da£ eine exklusive Sperre fur 
das Objekt gesetzt bzw. ein neuer Objekt-Wert erhalten 
worden ist (Abfrage 275) , der Transaktionsmanager zwecks 
Aufwecken des Objekts, Block 121 (s. auch Fig. 22), aufge- 
rufen. Je nach Verteilungsstrategie (SM) kann nach Block 274 
noch abgefragt werden, ob es eine Verlustnachricht fur das 
Objekt gab (wegen eines fatalen Fehlers) und dann 
Transaktions-Abort im Transaktionsmanager aufgerufen werden 
(ist in Fig. 32 zwecks Vereinf achung nicht dargestell t ) . Wenn 
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gemafi Abfrage 274 kein Objekt mehr vorhanden ist, wird vom 
Recoverymanager der "Atomare Schritt ENDE" bei Block 276 
durchgef lihrt . 

Behandle Nachricht von anderem Koordinat ions - Server : 
(CoKe) (s. Fig. 33) 
Hier wird einleitend im Schritt 277 die Strategie der 
erhaltenen Nachricht f estgehalten, und es wird sodann gemaS 
Block 278 die Prozedur "Bef ehl-Ausf uhren" (gemaS Fig. 32) 
hinsichtlich der Behandlung der Nachricht, die von einem 
CoKe kommt, aufgerufen. 

Obiekt soli gelesen werden: (s. Fig. 34) 

Hier wird einleitend die Strategie des zu lesenden Objekts 
im Schritt 279 f estgehalten, und dann wird wiederum im Block 
278 die Prozedur "Bef ehl-Ausf uhren" , hier hinsichtlich 
"Objekt soil gelesen werden" , aufgerufen. 

Exklusive Obi ekt-Sperre besoraen: (s. Fig. 35) 

Nachdem hier einleitend die Strategie des Objekts, fur das 
die exklusive Sperre besorgt werden Soli, f estgehalten wurde 
(Schritt 280) , wird im Block 278 die Prozedur "Befehl- 
Ausfuhren" : Exklusive Objekt-Sperre besorgen aufgerufen. 

Ist Obiekt exklusiv aesperrt : (s. Fig. 36) 

Nach Festhalten der Strategie des Objekts, fur das getestet 
werden soli, ob eine exklusive Sperre vorhanden ist, gemaS 
Schritt 281, folgt wieder die Prozedur "Bef ehl-Ausf uhren" 
(Block 278) , nun hinsichtlich der Abfrage, ob das Objekt 
exklusiv gesperrt ist. 

Prozefe-Schicken : (s. Fig. 37) 

Einleitend wird hier im Schritt 282 die Strategie des PID- 
Objekts des zu schickenden Prozesses f estgehalten, wonach im 
Schritt "Befehl-Ausfuhren" 278 der Prozefi geschickt wird. 

Signal -Schicken : (s. Fig. 38) 

Hier wird die Strategie des PID-Objekts des Prozesses 
f estgehalten, an den das Signal zu schicken ist (Schritt 
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283), bevor gemaS Block 278 das Signal geschickt wird. 

- Transf erieren transaktionaler Requests : (s. Fig. 39) 

Bevor gemaS Schritt 278 der Befehl ausgef lihrt und trans - 
aktionale Requests transf eriert werden, wird die Strategie 
der PID der Hilf stransaktion f estgehalten, deren Requests 
transf eriert werden sollen, s. Schritt 284 in Fig. 39. 

- Auf raumen : (Garbage Collection) (s. Fig. 40, Prozedur 238 in 

Fig. 28) 

Hier wird die Strategie des auf zuraumenden Objekts 
festgehalten (Schritt 285) , bevor die Auf raumarbeit (Garbage 
Collection) unter Ausfiihrung des Befehls, Block 278, 
erf olgt . 

Was die verwendbaren Strategien betrifft, so wird bevorzugt 
eine Basis- Strategie festgelegt und in der Regel verwendet . 
Basis-Strategien konnen z.B. PR_DEEP und AR_FLAT sein; dabei 
bedeutet PR_DEEP ("passive replication with deep object tree") 
eine passive Replikation bei einem in die Tiefe gehenden 
Objektbaum; AR__FLAT ("active replication with flat object tree") 
bedeutet eine aktive Replikation bei einem flachen Objektraum 
und bietet noch mehr Zuverlassigkeit und Verf ugbarkeit als 
PR_DEEP. Als Strategie-Flags (Protokollf lags) konnen unter 
anderem die Flags RELIABLE /UNRELIABLE ; MOBILE/NON_MOBILE ; 
GARB AGE_COLLECT I ON / NO_GARB AGE_COLLECT I ON ; SECURITY/NO_SECURITY ; 
TOPOLOGY_GRAPH / NO_TO POLOG Y_GRAPH eingesetzt werden. Hierbei 
bedeuten : 

RELIABLE/UNRELIABLE: ob kritische Zustandsanderungen im Daten- 
und Logfile gespeichert werden sollen, urn Recovery zu 
ermoglichen; 

MOB I LE / N0N_M0B I LE : ob ein Rechner im laufenden Betrieb 
intentional vom Netzwerk abgesteckt werden kann; 

GARBAGE_COLLECT I ON/NO_GARB AGE_COLLECT ION : ob das Objekt 

automat isch aufgeraumt werden soil, wenn es nicht mehr 
benotigt wird; 

SECURITY/NO — SECURITY : ob uberpriift werden soli, ob ein ProzeS 
autorisiert ist, auf ein Objekt zuzugreifen; 
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TOPOLOGY_GRAPH/NO_TOPOLOGY_GRAPH: ob ein Topologie-Graph als 
Hilf ststruktur verwaltet werden soil, der Information 
speichert, auf welchen Rechner sich Kopien des Objektes 
befinden, und damit das Replikationsverhalten fur sehr groSe 
Ob j ekte optimiert . 

Die Anwendung des vorliegenden Systems soli nun nachfolgend 
zusammen mit dabei erzielbaren Vorteilen anhand von zwei 
Anwendungsbeispielen noch naher erlautert werden. 

Beispiel 1: Produzent-Konsument 

Ein klassisches Beispiel fur die Verwaltung gemeinsamer 
Ressourcen ist das "Produzent-Konsument" Problem, bei dem eine 
beliebige Anzahl von verteilten, parallel laufenden Prozessen 
existiert, die entweder Daten produzieren oder Daten verarbeiten 
(= konsumieren) . Alle produzierten Daten sollen gleichberechtigt 
von jedem Konsumenten bezogen werden konnen (d.h. ohne 
Bevorzugung) , und sobald ein Datum konsumiert wurde, darf es 
kein weiteres Mai konsumiert werden. 

Eine auf " write -once " -Kommunikationsobj ekten basierende 
Losung mit Hilfe des beschriebenen Koordinat ions -Systems sieht 
als gemeinsame Datenorganisationsstruktur eine unendlich grofi 
werdende Liste vor, in die der Reihe nach die produzierten Daten 
geschrieben werden (eine solche Liste wird "Stream" genannt) 
Der Anfang der Liste wird durch ein Kommunikationsobj ekt , 
"Wurzel" genannt, dargestellt, in das der erste Produzent in 
einer Transaktion eine Listenzelle schreibt, die aus zwei 
Elementen besteht, namlich einem Kopf und einem Rumpf . In den 
Kopf schreibt der Produzent in derselben Transaktion sein Datum 
sowie ein neu angelegtes Kommunikationsobj ekt , genannt "Flag" , 
dessen Bedeutung weiter unten erklart wird. In den Rumpf 
schreibt der Produzent in derselben Transaktion ein weiteres neu 
angelegtes Kommunikationsobj ekt , genannt " ListenRumpf . 

"ListenRumpf " stellt den Rest der Liste dar, d.h. in diesen 
"ListenRumpf" wird der nachste Produzent wiederum in einer 
Transaktion eine Listenzelle hineinschreiben, die sein Datum, 
sowie ein neues Flag und einen neuen "ListenRumpf" enthalt 
u.s.w., vgl. auch die nachfolgende Tabelle 1: 
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Tabelle 1 



Datenorganisation als Stream 



Listenzelle 



Liste 



= [(Datuml, Flagl) 



Kopf der Liste 



ListenRumpf 1] 

< > 

Rumpf der Liste 



ListenRumpf 1 
ListenRumpf 2 



u. s . w. 



[ (Datum2 , Flag2) 
[ (Datum3 , Flag3) 



ListenRumpf 2] 
ListenRumpf 3 ] 



d.h. Liste [(Datuml, Flagl), (Datum2, Flag2), (Datum3, Flag3) 

ListenRumpf N] 



Die Synchronisation bei gleichzeit igem Schreibzugrif f meh- 
rerer Produzenten PR1 , . . . , PRk auf denselben ListenRumpf funk- 
tioniert f olgendermafien : da jeder Produzent PRi (i = 1, . . . , k) 
in einer Transaktion Tl , Tk auf das Kommunikationsob j ekt , 

das den ListenRumpf darstellt, zu schreiben versucht, kann nur 
eine dieser Transaktionen gutgehen { " kommitten" ) . Wenn 
angenommen die j-te Transaktion Tj erfolgreich war, d.h. der 
Produzent PRj sein Datum erfolgreich in den Stream geschrieben 
hat, dann rmissen alle anderen Produzenten PRi (i = 1, k und 

i <> j) die Schreibanf orderung auf den ListenRumpf in ihrer 
jeweiligen Transaktion Tj zurucknehmen ( "cancel" -Befehl) , den 
neuen Inhalt des ListenRumpf es auslesen, diesem den neuen 
ListenRumpf entnehmen und nun versuchen, die gewiinschte Listen- 
zelle mit dem produzierten Datum in den neuen ListenRumpf zu 
schreiben (als neu angemeldete Schreiboperat ion in der Trans- 
aktion T j ) . Unter der Annahme, dafi nicht immer zwei Produzenten 
existieren, die gleichzeitig auf denselben ListenRumpf zu 
schreiben versuchen, ist garantiert, da£ jeder Produzent seine 
Daten im gemeinsamen Stream zur Verfugung stellen kann. 

Urn ein Datum zu konsumieren, liest der jeweilige Konsument 
Ki den Stream soweit durch, bis er einen Eintrag findet, in dem 
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das "Flag" noch undefiniert ist, was bedeutet, da£ noch kein 
Konsument dieses Datum verarbeitet hat . Der Konsument Ki startet 
eine Transaktion und versucht in "Flag" den Wert "verarbeitet" 
hineinzuschreiben. Geht das Kommit der Transaktion gut, so kann 
der Konsument Ki nun das Datum verarbeiten. Geht das Transak- 
t ions -Kommit nicht gut, bedeutet dies, daS gerade ein anderer 
Konsument dieses Datum konsumiert hat, und der Konsument Ki muS 
die Schreiboperation auf "Flag" zuriicknehmen, die nachste 
Listenzelle aus dem aktuellen ListenRumpf lesen und - falls dort 
das Kommunikationsobjekt "Flag" noch undefiniert ist - nun 
neuerlich versuchen, in der Transaktion "Flag" auf "verarbeitet" 
zu setzen. Damit werden gleichzeitige Konsument enzugri f f e auf 
dasselbe Datum synchronisiert , und es ist garantiert, dafi jedes 
Datum von maximal einem Konsumenten verarbeitet wird. 

Jeder Produzenten- und Konsumentenprozefi wird als 
unabhangiger ProzeS angestartet, der als Argument das Wurzel - 
Kommunikationsobjekt der Liste (Anfang der Liste) mitbekommt . 
Damit hat jeder dieser Prozesse Zugriff auf alle 
produzierten/konsumierten Daten . 

Die Fehlertoleranz kann beim Anlegen aller verwendeten 
Kommunikationsobj ekte gesteuert werden: Es sei angenommen, dafi 
fur diese Kommunikationsobj ekte eine Verteilungsstrategie (siehe 
Tabellen 2, 3 und 4, Strategie PRX) gewahlt wurde , fur das die 
Option "RELIABLE" gesetzt ist. Dann ist das beschriebene 
Produzenten- Konsumenten- System sowohl gegen Systemfehler als 
auch gegen Netzwerkf ehler resistent . Beim Absturz eines Rechners 
wird der lokale Koordinations-Server wieder angestartet, dieser 
stellt alle Kommunikationsobj ekte sowie alle Produzenten- und 
Konsumentenprozesse wieder her und startet letztere mit dem 
urspriinglichen Wurzel -Kommunikationsobjekt als Parameter wieder 
an. Damit kann jeder dieser Prozesse wieder Zugang zu alien 
produzierten Daten im Stream erlangen und seine Arbeit wieder 
auf nehmen . Ein Konsument liest nun den Stream bis zum ersten 
Datum, dessen zugeordnetes Flag noch undefiniert ist; ein 
Produzent versucht, vom Wurzel -Kommunikationsobjekt ausgehend, 
beim ersten ListenRumpf, beim zweiten ListenRumpf, u.s.w. in den 
Stream zu schreiben; dabei wird es bei jedem schon beschriebenen 
Kommunikationsobjekt zu einem Transaktions-Kommit-Fehler kommen, 
der Produzent nimmt daher die Schreiboperation zuriick, uberliest 
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das beschriebene Kommunikationsobj ekt und probiert beim nachsten 
ListenRumpf weiter, bis er am Ende der Liste angelangt ist und 
dort sein Datum abstellen kann. Eine sinngemafie Optimierung kann 
noch fur diesen "Recovery " -Fall angebracht werden, in der die 
Logik des Produzenten so erweitert wird, da£ er immer testet 
(mit Hilf e von blockierendem Lesen) , ob ein ListenRumpf bereits 
definiert ist, bevor er seine Schreiboperation darauf ansetzt, 
und daS er, falls der ListenRumpf schon definiert ist, diesen 
sofort iiberliest. Netzwerkf ehler werden sowohl bei "RELIABLE" - 
als auch bei "UNRELIABLE" -Strategien maskiert, wobei letztere 
aber nur solange dafur garantieren konnen, solange keine Sys- 
temf ehler (Rechnerausf alle) auftreten. Dafiir ist iiblicherweise 
bei "UNRELIABLE" -Strategien mit einer besseren Performance zu 
rechnen; d.h. der Benutzer kann je nach Anwendungsbedurf nis die 
Fehlertoleranz- Performance am Kommunikationsobj ekt einstellen : 
das die Produzenten bzw. Konsumenten darstellende Programmsystem 
bleibt immer identisch. Weitere Abst imm-Moglichkeiten bestehen 
z.B. hinsichtlich der Verf iigbarkeit und des Replikationsver- 
haltens (d.h. auf welchem Rechner Kommunikationsobj ekt e 
tatsachlich Plattenplatz beanspruchen) . 

In der nachf olgenden Tabelle 2 ist die Logik des 
Produzenten, dem das Kommunikationsobj ekt WURZEL ubergeben 
wurde, in prozeduraler Pseudonotation veranschaulicht , wobei nur 
hier beispielshalber (in den nachf olgenden Tabellen nicht) auch 
die vorstehend angegebenen Namen fur die einzelnen Funktionen 
zusatzlich angefuhrt sind. 

Tabelle 2 

PRODUZENT (WURZEL) 

O: = WURZEL 
SCHLEIFE_1 : 

ERZEUGE NACHSTES DATUM 

ERZEUGE ZWEI NEUE KOMMUNIKATIONSOB JEKTE FLAG UND LISTENRUMPF 
VON STRATEGIE PRX 

("Anlegen von Kommunikationsobj ekt en" ) 
STARTE NEUE TOP- LEVEL- TRANS AKT I ON (= T) 

( " Top- Leve 1 - Transakt ions - Start " ) 
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SCHLEIFE_2 : 

WENN DAS N I CHT - BLOCK I ERENDE LESEN ("Lesen eines Objekts" ) 
VON 0 GUTGEHT: 

DER GELESENE WERT SEI DIE LISTENZELLE [KOPFjRUMPF] 

O: = RUMPF 

GOTO SCHLEIFE_2 

SCHREIBE IN T DEN WERT [ (DATUM, FLAG) [LISTENRUMPF] IN 0 
(= OPERATION OP1) ("Objekt-Schreiben") 
VERSUCHE T ZU KOMMITTEN ("Schwaches Transaktions-Kommit" ) 
WENN KOMMIT VON T GUTGEHT: 

O: = LISTENRUMPF 

GOTO SCHLEIFE_1 
ANSONST 

RUCKNAHME ("cancel") VON DER SCHREIBOPERATION (OP1) AUF 
0 IN T 

GOTO SCHLEIFE_2 

In Tabelle 3 ist die Logik des Konsumenten, dem das 
Kommunikationsobjekt WURZEL ubergeben wurde, in prozeduraler 
Pseudonotation veranschaulicht : 

Tabelle 3 

KONSUMENT (WURZEL) 

O: = WURZEL 
SCHLEIFE_3 : 

STARTE NEUE TO P - LEVEL - TRANS AKT I ON (= T) 
SCHLEIFE_4 : 

BLOCKI ERENDES LESEN VON 0: 

DER GELESENE WERT SEI DIE LISTENZELLE [ (DATUM, 
FLAG) (LISTENRUMPF] 
0: = LISTENRUMPF 
WENN FLAG DEFINIERT IST 

GOTO SCHLEIFE_4 
ANSONST 

SCHREIBE IN T DEN WERT " VERARBE I TET " IN FLAG 
( = OPERATION 0P2) 
VERSUCHE T ZU KOMMITTEN ("Schwaches Transaktions-Kommit") 
WENN KOMMIT VON T GUT GEHT : 



WO 98/14870 



PCT/AT97/00209 



- 57 - 

VERARBEITE DATUM 
GOTO SCHLEIFE__3 
ANSONST 

RUCKNAHME VON DER SCHREIBOPERATION (OP2) AUF FLAG IN T 
GOTO SCHLEIFE 4 



Die nachfolgende Tabelle 4 zeigt das Anstarten von N 
Produzentenprozessen und M Konsumentenprozessen auf den Rechnern 
Ri . . . RN bzw. Rl . . . RM : 



Tabelle 4 



ERZEUGE NEUES KOMMUNI RATIONS OB JEKT WURZEL VON STRATEGIE PRX 



STARTE UNABHANG I GEN PROZESS 
AUSZUFUHRENDE FUNKTION 

STARTE UNABHANG I GEN PROZESS 
AUSZUFUHRENDE FUNKTION 

STARTE UNABHANG I GEN PROZESS 
AUSZUFUHRENDE FUNKTION 



PP1 AUF RECHNER Rl ; DIE 
SEI PRODUZENT (WURZEL) 
PP2 AUF RECHNER R2 ; DIE 
SEI PRODUZENT (WURZEL) 

PPN AUF RECHNER RN; DIE 
SEI PRODUZENT (WURZEL) 



STARTE UNABHANG I GEN PROZESS KP1 AUF RECHNER Rl ; DIE 

AUSZUFUHRENDE FUNKTION SEI KONSUMENT (WURZEL) 

STARTE UNABHANG I GEN PROZESS KP2 AUF RECHNER R2 ; DIE 

AUSZUFUHRENDE FUNKTION SEI KONSUMENT (WURZEL) 

STARTE UNABHANG I GEN PROZESS KPM AUF RECHNER RM; DIE 
AUSZUFUHRENDE FUNKTION SEI KONSUMENT (WURZEL) 

Dieses Beispiel demonstriert auch die Moglichkeit, unendlich 
lang laufende Prozesse zu spezif izieren : sowohl die Produzenten- 
als auch die Konsumentenprozesse laufen unendlich und uberleben 
sowohl System- als auch Netzwerkf ehler , sofern eine "RELIABLE" - 
Verteilungsstrategie gewahlt wurde . 

Das Hinzunehmen neuer Produzenten und Konsumenten (auf ver- 
teilten Rechnern) erfolgt dynamisch ("dynamic scale-up") durch 
Anstarten eines Prozesses auf dem entsprechenden Rechner, dem 
das Wurzel-Kommunikationsobjekt als Parameter ubergeben wird. 
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Eine Autorisierung ist abhangig von der gewahlten Vertei- 
lungsstrategie gegeben, indem nur ein dezidiert als Konsument 
resp. als Produzent angestarteter ProzeS auf die Daten des 
Streams zugreifen darf . Wenn angenommen in der verteilten 
Umgebung noch weitere parallel laufende Prozesse existieren, 
dann darf keiner dieser Prozesse auf die Stream-Daten zugreifen, 
selbst wenn er zufallig die Objektidentif ikationsnummer eines im 
Stream enthaltenen Kommunikationsobjekts "errat", wobei davon 
ausgegangen wird, da£ dieses Kommunikationsobjekt weder in der 
ihm iibergebenen Parameterliste aufscheint, noch als Unter- 
Kommunikationsobjekt in ein fur diesen Prozefi zugangliches 
Kommunikationsobjekt geschrieben wurde, noch von diesem Prozefi 
angelegt wurde. 

Bekannte Werkzeuge fur verteiltes Programmieren erlaubten 
eine dermafien einfache und kurze Spezif ikation dieses 
klassischen Problems nicht, bei der der Programmierer vollig von 
Hardware- und Netzwerkaspekten befreit wird und trotzdem die 
Moglichkeit hat, die Performance etc. des Programms vollig 
seinen Anwendungsbediirf nissen anzupassen. 

Das Produzenten-Konsumenten-Problem findet sich als Grund- 
schema in einer breiten Klasse von verteilten Anwendungs- 
problemen wieder, wie zum Beispiel im verteilten Banking, wo die 
gemeinsamen Tresorreserven verteilter Bankschalter als Stream 
verwaltet werden, oder die Verwaltung von Workflow Daten. 

Beispiel 2: Reisebuchung 

Es soli eine Reise arrangiert werden, zu der folgende 
Buchungen benotigt werden: ein Flug von Wien nach Paris, ein 
Hotelzimmer in Paris und ein Auto in Paris. Der Flug kann bei 
einer von drei Fluglinien A, B oder C gebucht werden. Das 
Hotelzimmer kann entweder im Hotel H oder im Hotel I gebucht 
werden. Das Auto kann bei einem Autoverleih V oder W gemietet 
werden. Es wird angenommen, da6 der Kunde keine Buchungspra- 
ferenzen vorgibt . Weiters gilt, da£ eine Flugbuchung storniert 
werden kann. Es ist dann "STORNO der Buchung" als Kompensations- 
aktion in der entsprechenden Flugliniendatenbank aufzurufen. 
Daher braucht man nicht zu fordern, dafi das lokale Datenbank- 
system der Fluglinie ein 2 - Phasen-Kommit bietet, d.h. die 
Flugbuchungstransaktion kann dort ehestmoglich abgeschlossen 
werden, damit die lokale Flugliniendatenbank nicht zu lange von 
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der globalen Reisebuchungstransaktion blockiert wird. 

Hotelbuchungs- und Autovermietungstransaktionen sollen nicht 
kompensierbar sein, d.h. hier mufi gefordert werden, daS die 
jeweiligen Datenbanken ein 2 -Phasen-Kommit vorsehen und in der 
Lage sind, die Sperren auf die betroffenen Daten bis zum Kommit 
der globalen Reisebuchungstransaktion zu halten. 

Es gibt im vorliegenden Koordinations-System mehrere Mog- 
lichkeiten, dieses Problem zu losen, die einen unterschiedlichen 
Grad an Parallelitat garantieren. Die im folgenden gezeigte 
Losung bietet eine maximale Parallelitat. 

Die gesamte Reisebuchung ist als Transaktion T dargestellt. 
Alle Flugbuchungen werden parallel als unabhangige Prozesse (die 
selbstandig kommitten) angestartet, die die Hilf sf unktion 
K BUCHEN ausfuhren. K_BUCHEN steht fur "kompensierbares Buchen" . 
Zu beachten ist, daS unabhangige Prozesse implizit eine neue 
Top-Level -Transaktion starten, die als "Hilf stransaktion des 
unabhangigen Prozesses" bezeichnet wird und abhangig vom 
spezif izierten Exit -Wert des Prozesses automatisch entweder 
abgebrochen oder kommitted wird. Die Funktion K_BUCHEN startet 
die Transaktion "Buchen" in der Datenbank der entsprechenden 
Institution. Wenn die Buchung im Datenbanksystem DBS durchge- 
fuhrt (und sofort kommitted) wurde, meldet K_BUCHEN die Aktion 
"STORNO der Buchung" als Kompensat ionsaktion in der Transaktion 
des unabhangigen Prozesses an (d.h. wenn dieser Prozefi 
zuruckgenommen ("cancel") oder abgebrochen ("abort") wird, 
nachdem er schon erfolgreich terminiert hatte, wird automatisch 
diese Aktion durchgef uhrt ) und terminiert den ProzeS mit dem 
Exit-Wert "PREPARE". Dies bedeutet, da£ der Prozefi noch auf 
eines der Signale "ABORT", "CANCEL" oder "COMMIT" wartet . Das 
Verhalten des Prozesses im Fall der ersten beiden Signale ist 
wie schon erwahnt das Abbrechen seiner Transaktion, die die 
Ausfiihrung der Kompensat ionsaktion "STORNO von Buchung im DBS" 
triggert. Ein Signal "COMMIT" schliefit die Arbeit des Prozesses 
ab, so dafc dieser ab nun keine Signale mehr akzeptiert; die 
Buchung ist dann endgiiltig abgeschlossen . 

Die Hotel- und Autobuchungen werden ebenfalls parallel, aber 
als abhangige Prozesse angestartet, die die Funktion NK_BUCHEN 
("nicht kompensierbares Buchen") ausfuhren. Diese Funktion star- 
tet die Transaktion "Buchen" in der Datenbank der entsprechenden 
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Institution. Wenn die Buchung im Datenbanksystem DBS erfolgreich 
ist, meldet das DBS " DB_READY 11 zuriick, d,h. das DBS wartet nun 
solange, bis ihm ein " DB_COMMIT" oder ein "DB_ABORT " geschickt 
wird. Erst nach einem "DB_COMMIT" werden die Anderungen im DBS 
sichtbar. Wenn das DBS ein "DB^READY" retourniert, meldet 
NK_BUCHEN " DB^COMMIT" im DBS als Kommitaktion im aktuellen 
Prozefi an, d.h. diese Kommit-Aktion bezieht sich auf die Trans - 
aktion des aktuellen Prozesses, die im Fall eines abhangigen 
Prozesses jene Transaktion ist, von der der ProzeS aufgerufen 
wurde, im vorliegenden Beispiel daher die Transaktion T. Diese 
Kommit-Aktion wird daher genau dann angestartet, wenn die 
Transaktion gutgeht . 

Nachdem alle Buchungen als parallel laufende Prozesse 
angestartet worden sind, synchronisiert die Transaktion T diese 
Prozesse. Dazu werden zwei Hilf sf unktionen 

WARTE_AUF_UNABHANGIGEN_PROZESS und WARTE_AUF_ABHANGIGEN_PROZESS 
verwendet . Beide Funktionen verwenden das blockierende "Alter- 
native Warten" (ALT__WAIT) -Konstrukt , urn auf alle ubergebenen 
ProzeSidentif izierer (PIDs) zu warten, die ja Kommunikat ions- 
objekte sind. Sobald ein ProzeS terminiert, setzt er automatisch 
seine PID auf den Ausgangszustand, der uber den Exit-Wert des 
Prozesses spezifiziert wurde . Wenn also der gewiinschte Exit-Wert 
" PREPARE " und der ProzeS ein unabhangiger (oder aber abhangiger) 
Prozefi ist, dann wird die PID auf "SUCCEEDED" (oder aber 
"PREPARED") gesetzt, falls die Hilf stransakt ion des unabhangigen 
Prozesses erfolgreich terminieren konnte (bzw. falls die 
Hilf stransaktion des abhangigen Prozesses noch Chancen hat zu 
kommitten) . Der Wert der PID wird nun getestet, wenn das 
ALT_WAIT aktiv wird. 

War der beendete ProzeS erfolgreich, dann schickt die 
Hilf sfunkt ion WARTE_AUF_UNABHANGIGEN_PROZESS das Signal "ABORT" 
an alle anderen Prozesse, meldet das Schicken des Signals 
" COMMIT" an den erf olgreichen ProzeS als Kommit-Aktion der 
Transaktion T an (d.h. das Triggern des "DB_COMMIT" wird an die 
Transaktion T delegiert) und gibt "OK" zuriick . Ansonst schickt 
die Hilf sfunktion WARTE_AUF_UNABHANGIGEN_PROZESS das Signal 
"ABORT" an den Prozefi, der zwar das ALT_WAIT aktiviert hat, aber 
nicht erfolgreich terminierte, und startet erneut ein ALT__WAIT 
auf alle anderen Prozesse an. 
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Die Hilf sf unktion WART E_AUF_AB HANG I GEN_PRO ZES S verhalt sich 
folgendermafien: War der beendete Prozefi erfolgreich, dann nimmt 
die Hilf sfunktion WART E_AUF_AB HANG I GEN_PRO Z E S S alle anderen 
abhangigen Prozesse in Bezug auf T zuriick ("cancel") und gibt 
"OK" zuriick. Dieses Rucksetzen ("cancel") entfernt einerseits 
den abhangigen Prozefi aus den Aktionen, die T ausfiihren muE (so 
als ob dieser abhangige Prozefi nie von T aufgerufen worden ware 
- das demonstriert die Eigenschaft des Zuriicknehmens ("Trans- 
aktions-Backtracking" ) des Koordinat ions -System) und schickt 
andererseits auch das Signal "ABORT" an den ProzeS, was wiederum 
den Abbruch aller direkten Untertransaktionen von T bewirkt, in 
vorliegendem Fall von Ti, d.h. die Kompensationsaktion ( = 
DB_ABORT im DBS, das noch immer im 2 - Phasen-Kommit wartet) der 
Transaktion Tl wird ausgefiihrt, da Tl schon erfolgreich termi- 
niert hatte. War der beendete ProzeS nicht erfolgreich, nimmt 
die Hilf sfunktion WARTE_AUF_ABHAENGIGEN__PROZESS den abhangigen 
Prozefi (das ist wieder eine Anwendung von "Transaktions- 
Backtracking" ) in Bezug auf T zuriick und startet erneut ein 
ALT_WAIT auf alle anderen Prozesse. 

Dieses Beispiel demonstriert, wie das Koordinationssystem 
als Steuerung fiir echte Datenbanktransaktionen dienen kann, 
wobei die Datenbanken autonom, d.h. unterschiedlich, sein konnen 
in Hinblick auf den unterstiitzten Transaktionsmechanismus . 
Speziell wurde gezeigt, da£ Datenbanken, die ein herkommliches 
2 -Phasen-Kommit unterstiitzen, und Datenbanken, die diese Eigen- 
schaft nicht aufweisen, in einer einzigen globalen Transaktion 
koordiniert werden konnen, wobei die Eigenschaft der Aufhebung 
der Isolation von Transaktionen des Koordinat ionsmodells 
ausgenutzt wurde . 

Weiters wird demonstriert, dafi es mit Hilfe des 
Koordinat ions -System moglich ist, eine globale Transaktion zu 
koordinieren, fiir deren Untertransaktionen alternative 
Losungsmoglichkeiten exist ieren, und da£ auch die Kombination 
von " 2 -Phasen-Kommit " / "kein 2 -Phasen-Kommit " moglich ist. Es 
wird garantiert, daS nur genau die benotigten Datenbank-Trans - 
aktionen abgeschlossen werden, d.h. dafi z.B. nicht zwei Fliige 
gebucht werden oder zwei Hotels . Wenn angenommen zwei Flug- 
linien-Datenbanken gleichzeitig einen Flug "kommitted" haben, 
dann wird im ALT_WAIT der Hilf sfunktion 
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WARTE_AUFJUNABHANGIGEN_PROZESS indeterminist isch ein Flug 
gewahlt (das wird der Prozefi sein, dessen PID schneller gesetzt 
wurde) , und alle anderen Flugbuchungsprozesse werden 
abgebrochen. Wenn angenommen zwei Hotelbuchungs-Datenbank- 
Transaktionen gleichzeitig "DB_READY" gemeldet haben, dann wird 
die Hilf sfunktion WARTE_AUF_EINEN_ABHANGIGEN_PROZESS in ■ ihrem 
ALT_WAIT auch einen der Prozesse, die diese Buchung 
ref lektieren, indeterministisch auswahlen und den anderen ProzeS 
zuriicknehmen ("cancel"), was das Schicken des " DB_AB0RT " an die 
entsprechende Hoteldatenbank triggert . 

Wird fur eine Buchungsgruppe (Flug/Hotel/Auto) keine Losung 
gefunden, dann wird ein Abbruch der globalen Transaktion 
aufgerufen, was wiederum ein "Abort" aller bisher erf olgreichen 
Buchungen bewirkt, so da£ zum Schlufi keine Buchung durchgefuhrt 
wurde . 

Trotz all dieser Eigenschaf ten garantiert die Transaktion T 
die Atomizitat der globalen Transaktion auch im Fall von 
Netzwerkf ehlern. Ob im Fall von Systemf ehlern auch Atomizitat 
garantiert wird, hangt von der Verteilungsstrategie ab, die beim 
Anlegen der Prozefiidentif izierer (PID) nach dem Start von T 
gewahlt wurde. 1st die Strategie ein zuverlassiges Protokoll 
("RELIABLE"), so wird auch im Fall eines Systemf ehlers 
Atomizitat bewahrt . Wenn angenommen der Rechner, auf dem die 
Transaktion T lauft, nachdem alle Prozesse parallel angestartet 
wurden, absturzt, und weiters angenommen wird, da& alle Prozesse 
auf anderen Rechnern laufen als jenem, auf dem T lauft, und dafi 
z.B ein Hotelbuchungsprozefi (z.B. bei Hotel I) bereits 
erfolgreich terminiert hat, mufi nun, da die globale Transaktion 
durch den Absturz abgebrochen wurde, garantiert werden, da£ die 
Hotelbuchung nicht durchgefuhrt wird. Beim Wiederanstart des 
Koordinations-Servers auf dem Rechner von T wird der Prozefi- 
identif izierer PID_Hotel I gefunden und erkannt, da£ es sich urn 
die PID eines abhangigen Prozesses handelt, dessen Transaktion 
abgebrochen wurde. Daher wird automatisch das Signal "ABORT" an 
diesen ProzeS geschickt, was das "DB_ABORT" der Hotelbuchung 
triggert. Wenn jetzt angenommen wird, da£ auch eine Flugbuchung 
gutgegangen ist, so ist im gezeigten Beispiel kein Mechanismus 
vorgesehen, der wie bei der Hotelbuchung automatisch das Storno 
triggert. Da aber Flugbuchungen kompensierbar sind, wird davon 
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ausgegangen, da£ der Benutzer, wenn die Rechnung fur den Flug 
kommt , ein Storno an die Fluglinie schickt. Es ist aber nicht 
kompliziert, die Transaktion T so zu andern, dafi auch im Fall 
einer Flugbuchung (d.h. der mittels eines unabhangigen Prozesses 
gesteuerten Dat enbank - Transakt ion) ein Abbruch automatisch 
erfolgt, wenn T abgebrochen wurde . Die notwendige Abanderung des 
Beispiels dahingehend besteht ausschlieSlich darin, Flugbuchun- 
gen auch als abhangige Prozesse anzustarten (und diese auch mit 
der Funktion WARTE_AUF_EINEN_ABHANGIGEN_PROZESS zu synchronisie- 
ren) , wobei unverandert die Funktion K_BUCHEN aufgerufen wird. 

Die Einstellbarkeit hinsichtlich Fehlertoleranz ist somit 
leicht iiber die Auswahl der verwendeten Verteilungsstrategie 
steuerbar. Weiters ist es sehr leicht, die Semantik des 
Beispiels abhangig von anderen Anf orderungen abzuandern. Meist 
reicht die Modifikation weniger Zeilen; dies ist durch die 
Machtigkeit der vom Koordinations-System unterstiit zten 
Kontrollmechanismen erklarbar. 

Die gezeigte Transaktion T kann als Komponente (d.h. als 
Untertransaktion) in anderen Transakt ionen verwendet werden. Sie 
demonstriert die Eigenschaft des nicht -kaskadierenden Kompen- 
sierens : wenn T kommitted hat, kann T nur noch als gesamtes 
Arrangement storniert werden, d.h. sollte die T umschlieSende 
Transaktion, nachdem T bereits gutgegangen ist, abgebrochen 
werden, dann wird fur T die Kompensat ionsakt ion "STORNO der 
Parisreise" aufgerufen; damit kann die Reise, deren Hotel- und 
Autobuchungsunterkomponenten nicht kompensierbar waren, 
kompensiert werden . 

Nachfolgend wird in Tabelle 5 dieses Buchungsbeispiel in 
prozeduraler Pseudonotat ion veranschaulicht . 

Tabelle 5 

FUNKTION K_BUCHEN (DBS) 

RUFE "BUCHEN" IN DBS AUF 
WENN BUCHUNG GUTGING : 

WENN DAS DBS 2 - PHASEN_KOMMIT UNTERSTUTZT : SCHICKE 

11 DB_KOMM IT" AN DAS DBS 
MELDE IM AKTUELLEN PROZESS "STORNO VON BUCHUNG IN DBS" 
ALS KOM PENS AT I ONS AKT I ON AN 



WO 98/14870 



PCT/AT97/00209 



- 64 - 



RUFE EXIT VON PROZESS MIT DEM EXIT-WERT "PREPARE" AUF 
ANSONST: RUFE EXIT VOM PROZESS MIT DEM EXIT-WERT "ABORT" AUF 

FUNKTION NK_BUCHEN(DBS) 

RUFE "BUCHEN" IN DBS AUF 

WENN BUCHUNG GUTGING (D.H. DBS HAT "DB_READY" GEMELDET) : 
MELDE IM AKTUELLEN PROZESS "DB_COMMIT IN DBS" ALS 

KOMM IT- AKT ION AN 
STARTE IN T EINE UNTERTRANS AKT I ON Tl 

MELDE IN Tl "DB_ABORT IN DBS" ALS KOM P ENS AT I ONS AKT I ON 
AN 

KOMMITTE Tl 

RUFE EXIT VOM PROZESS MIT DEM EXIT-WERT "PREPARE" AUF 
ANSONST: RUFE EXIT VOM PROZESS MIT DEM EXIT-WERT "ABORT" AUF 

STARTE TRANS AKT I ON T 

LEGE NEUE KOMMUN I KAT I ONS OB JEKTE FUR DIE PROZESSIDENTIFIZIE- 
RER PID_A, PID_B, PID_C, PID_H, PID_I, PID__V UND 
PID_W VON DER VERTE I LUNGS S TRATEG I E PRY AN 

^STARTE UNABHANGIGEN PROZESS (PID A) AUF DEM RECHNER DER 



FLUGLINIE A, DER DIE FUNKTION K BUCHEN (A DBS) 



AUFRUFT 



STARTE 



UNABHANGIGEN PROZESS (PID_B AUF DEM RECHNER 

DER FLUGLINIE B, DER DIE FUNKTION K BUCHEN (B DBS) 



AUFRUFT 



STARTE 



UNABHANGIGEN PROZESS (PID C) AUF DEM RECHNER DER 



FLUGLINIE C, DER DIE FUNKTION K BUCHEN (C DBS) 



AUFRUFT 



STARTE 



ABHANG I GEN PROZESS (PID_H) AUF DEM RECHNER DER 

H-HOTELKETTE, DER DIE FUNKTION NK BUCHEN (H DBS) 



AUFRUFT 



STARTE 



ABHANG I GEN PROZESS (PID_I) AUF DEM RECHNER DER 

H-HOTELKETTE, DER DIE FUNKTION NK BUCHEN ( I DBS) 



AUFRUFT 
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STARTE ABHANGIGEN PROZESS (PID_V) AUF DEM RECHNER DES 

AUTOVERMIETERS V, DER DIE FUNKTION 

NK_BUCHEN ( V_DB S ) AUFRUFT 
STARTE ABHANGIGEN PROZESS (PID_W) AUF DEM RECHNER DES 

AUTOVERMIETERS W, DER DIE FUNKTION 

NK_BUCHEN(W_DBS) AUFRUFT 

WENN (WARTE_AUF_ABHANGIGEN PROZESS (T, PID_A, PID_B, PID_C) 
= "OK" UND 

( WART E_AUF__UNABHANG I GEN_PRO Z E S S (T, PID_H, PID_I) 
= "OK") UND 

(WARTE_AUF_UNABHANGIGEN_PROZESS (T, PID_V, PID_W) 
= "OK") 

MELDE "STORNO DER PARIS -REISE " ALS KOMPENS AT I ONS AKT I ON 

VON T AN 
RUFE KOMMIT VON T AUF 

INFORMIERE KUNDEN UBER DIE RE I S EBUCHUNG 
ANSONST 

RUFE ABORT VON T AUF 

INFORMIERE KUNDEN, DASS DIE REISE NICHT GEBUCHT WURDE 

FUNKTION WARTE_AUF_UNABHANGIGEN_PROZESS (T, PID1, PID2 , . . .) 

WARTELISTE SEI DIE LISTE DER PROZESS IDENTIFIZ I ERER PID1 , 
PID2 

LxABEL : 

WENN WARTELISTE LEER 1ST: RETOURNI ERE "NICHT 0K M 
WARTE MIT ALT_WAIT AUF WARTELISTE: DER GEFEUERTE 
PROZ ES S I DENT I F I Z I ERER SEI PID_I 
ENTFERNE PID_I AUS DER WARTELISTE 
WENN IN PID_I "SUCCEEDED" STEHT : 

SCHICKE SIGNAL ABORT AN ALLE PROZESS I DENT I F I Z I ERER IN 
DER WARTELISTE 

MELDE IN T "SCHICKE SIGNAL KOMMIT AN PID_I" ALS 
KOMMIT -AKTION AN 

RETOURNI ERE "OK" 
ANSONST 

SCHICKE SIGNAL ABORT AN PID_I 
GOTO LABEL 1 
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FUNKTION WARTE_AUF_EINEN_ABHANGIGEN_J>ROZESS (T, PID1, PID2, . ..) 
WARTELISTE SEI DIE LISTE DER PROZ ES S I DENT I F I Z I ERER PID1, 
PID2, .... 

LABEL: 

WENN WARTELISTE LEER 1ST: RETOURNIERE "NICHT 0K n 
WARTE MIT ALTJWAIT AUF WARTELISTE: DER GEFEUERTE 
PROZESSIDENTIFIZIERER SEI PID_I 
ENTFERNE PID_I AUS DER WARTELISTE 
WENN IN PID_I "PREPARED" STEHT : 

CANCEL ALLER PROZESSIDENTIFIZIERER IN DER WARTELISTE 
IN BEZUG AUF T 

RETOURNIERE "OK" 
ANSONST 

RUCKNAHME VON PID_I IN BEZUG AUF T 
GOTO LABEL 1 



Wenn die Erfindung vorstehend anhand von detaillierten 
bevorzugten Ausf iihrungsbeispielen naher erlautert wurde, so sind 
doch selbstverstandlich Abwandlungen und Modif ikationen im 
Rahmen der Erfindung moglich. So sind selbstverstandlich die 
angegebenen Funktionsbezeichnungen beliebig, und die Funktionen 
konnen auch im Ablauf getauscht werden. 
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Patentanspruche : 

1. System zur Koordination verteilter Programme, Dienstleistun- 
gen und Daten mit Hilfe von Anwendungsprogrammen in einem 
Netzwerk mit Rechnern, auf denen lokale Sof twaresysteme (LSYS) 
(18, 19, 20) bedienende Koordinations- Server (CoKe) (21, 22, 23) 
laufen, wobei gemeinsame Objekte (9) als Kommunikationsobj ekte 
zum Austausch von Nachrichten eingesetzt und Transaktionen zur 
Realisierung von Kommunikation verwendet werden, und die 
Kommunikationsobj ekte (9) durch Objektidentif ikationsnummern 
(OID) eindeutig ident if iziert werden und nur Prozesse mit einer 
Referenz auf ein Kommunikationsob j ekt auf dieses iiber den 
jeweiligen lokalen Koordinations-Server zugreifen durfen, 

dadurch gekennzeichnet , 

dafi alle Koordinations-Server (21, 22, 23) zusammen als 
globales Betriebssystem (24) festgelegt sind, 

daS die lokalen Sof twaresysteme (18, 19, 20) zumindest durch 
Funktionen zur Kontrolle von Transaktionen, zum Anlegen und 
blockierenden oder nicht-blockierenden Lesen von Kommunika- 
tionsobj ekten, zur Spezif ikation von transakt ionalen Pradikaten 
sowie zur Erzeugung und Uberwachung von eindeutig identif izier- 
ten, zum Zugreifen auf libergebene Kommunikationsobj ekte 
autorisierten Prozessen erweitert sind, 

und da£ die Kommunikationsobj ekte (9) mit Hilfe von auf 
Repl ikation beruhenden wahlbaren Verteilungsstrategien verwaltet 
werden, von denen Anwendungsprogramme unabhangig sind. 

2. System nach Anspruch 1, dadurch gekennzeichnet, da£ bei der 
Wahl der jeweiligen Verteilungsstrategie eine Basis-Strategie in 
Verbindung mit zusatzlichen, optionalen Strategief lags gewahlt 
wird . 

3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, da£ 
die lokalen Sof twaresysteme vom jeweiligen Koordinations-Server 
(21, 22, 23) gestartet werden. 

4 . System nach einem der Anspriiche 1 bis 3 , dadurch gekenn- 
zeichnet, daS Kommunikationsobj ekte (9), auf die kein lokal 
laufender Prozefc mehr eine Referenz hat, vom jeweiligen 
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Koordinat ions -Server (21, 22, 23) automat isch geldscht oder 
ausdrucklich freigegeben werden. 

5. System nach einem der Anspriiche 1 bis 4, dadurch gekenn- 
zeichnet, da£ uber die sich in ihrer Gesamtheit als globales 
Betriebssystem (24) verhaltenden Koordinat ions -Server (21, 22, 
23) heterogene Transaktionen bzw. Unter-Transaktionen auf 
verschiedene Rechner (X, Y, Z) verteilt werden. 

6 . System nach einem der Anspriiche 1 bis 5 , dadurch 
gekennzeichnet, da£ im Falle von aktualisierbaren Objekten ein 
transaktionales Lesen dieser Objekte vorgesehen ist. 

7. System nach einem der Anspriiche 1 bis 5, dadurch gekenn- 
zeichnet, daS als transaktionales Pradikat das Schreiben in ein 
Objekt, das Starten einer Untertransaktion, das Verteilen eines 
Teils einer Transaktion auf einen anderen Rechner, das 

Spezif izieren einer Kompensationsaktion bzw. einer Kommit-Aktion 
vorgesehen sind. 

8. System nach einem der Anspriiche 1 bis 7, dadurch 
gekennzeichnet, da£ dann, wenn sicher ist, daS eine jeweilige 
Transaktion eine Vollzugsmeldung abgeben (kommitten) wird, eine 
Kommit-Aktion als Berechnung angestartet wird. 

9. System nach einem der Anspriiche 1 bis 8, dadurch gekenn- 
zeichnet, dafi unter den Funktionen fur Transaktionen ein 
programmierbares Riicksetzen von transaktionalen Operationen, wie 
z.B. das Lesen oder Schreiben von Kommunikationsob j ekten (9), 
fur den Fall, Fehler bzw. Ausfalle in den Transaktionen 
dynamisch reparieren zu konnen, vorgesehen ist. 
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Erzeugen einer neuen OID 
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ObjektBCaCUS : = UNDEFINED 
Objektxeitmarke := 0 
Objekcscrategie := Strategic 
Objekttyp := Typ; 
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und i s t sie im Zustand STARTED oder FAILED? 



Erzeugen einer eindeutigen TID; 
An leg en einer Transaktionsstniktur; 
Tr ansa Jet ions -Vater : = TIDvater; 
Ausfuehrungszustand := STARTED; 
Trans akt ions -Typ := normal; 
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INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



^rnational application No. 

PCT/AT97/00209 



I. Basis of the report 



1 This report has been drawn on the basis of {Replacement sheets which have been furnished to the receiving Office in response to an invitation 
under Article 14 are referred to in this report as " originally filed" and are not annexed to the report since they do not contain amendments.): 

| | the international application as originally filed. 

the description, pages 1-66 , as originally filed, 

pages , filed with the demand, 

pages , filed with the letter of » 

pages , filed with the letter of 



El 



the claims, 



Nos. 
Nos. 
Nos. 
Nos. 
Nos. 



1-9 



, as originally filed, 

, as amended under Article 19, 

, filed with the demand, 

, filed with the letter of 12 November 1998 (12.11.1998) 
, filed with the letter of 



^ the drawings, 



sheets/fig . 
sheets/fig 
sheets/fig 
sheets/fig 



1/22-22/22 



, as originally filed, 
, filed with the demand, 
, filed with the letter of 
, filed with the letter of 



2. The amendments have resulted in the cancellation of: 

1 1 the description, pages 

1 1 the claims, Nos. 



| 1 the drawings, sheets/fig 



3 I I This report has been established as if (some of) the amendments had not been made, since they have been considered 
' — ' to go beyond the disclosure as filed, as indicated in the Supplemental Box (Rule 70.2(c)). 



4. Additional observations, if necessary: 



Form PCT/IPEA/409 (Box I) (January 1994) 



I 

I 



THIS PAGE BLANK mm) 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



^^national application No. 
PCT/AT 97/00209 



V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 



Statement 
Novelty (N) 

Inventive step (IS) 
Industrial applicability (IA) 



Claims 
Claims 

Claims 
Claims 

Claims 
Claims 



1-9 



1-9 



1-9 



YES 
NO 
YES 
NO 

YES 
NO 



Citations and explanations 

1. This report makes reference to the following 
document : 



Dl : KUHN E.: "Fault - tolerance for communicating 
multidatabase transactions", PROCEEDINGS OF THE 
TWENTY -SEVENTH HAWAII INTERNATIONAL. CONFERENCE ON 
SYSTEM SCIENCES, Vol. II: SOFTWARE TECHNOLOGY (CAT. 
NO. 94TH0607-2) , PROCEEDINGS OF THE TWENTY- SEVENTH 
ANNUAL HAWAII INTERNATIONAL CONFERENCE ON SYSTEM 
SCIENCES, WAILEA, HI, USA, 4-7, ISBN 0-8186-5060-5, 
19 94, LOS ALAMITOS, CA, USA, IEEE COMPUT . SOC . 
PRESS, USA, pages 323-332. 

2. A system as defined in the preamble of Claim 1 is 
known from Dl . 



3. Proceeding from this prior art, the problem 

addressed by the invention is to devise a new system 
of... the above-mentioned type, which allows setting 
up robust distributed applications... in a simple 
and reliable manner, . . . and which avoids the 
disadvantages of known solutions by means of 
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(a) 



(b) 



(c) 



parHmlar franaa c Hnn concents at the Homipurucat ion 
level and the possibility of selecting several 
Hi^rihntj nn Btratsaiea (present application, page 
5, paragraph 3) . 

This problem is solved essentially in that 

all coordination servers have an identical object 
transaction and process management basic function 
and define together a global operating system; 

at least some objects are updatable, the functions 
provided to extend the local software systems make 
it possible to read the updatable objects in a 
transactional blocking way and the processes are 
allowed to access transmitted communication objects; 
and 

distribution strategies on which the application 
programs do not depend are provided to manage the 
communication objects and can be selected to re- 
establish or not communication objects and 
processes . 

Pe feature (a) ; 

The advantages resulting from feature (a) are 
described on page 6, lines 12-25 of the present 
description . 

Feature (a) is not found in Dl . 
R° f^arm-e lb) : 

Feature (b) provides updatable objects which can be 
read in a transactional blocking manner (see 
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description, page 1'3 , last four lines, to page 14, 
line 28; pages 21/22, paragraph: "Setting up an 
Object"; pages 36/37, paragraph: "Reading 
Transactional Objects''). 

In lines 7-10 of page 21 of the description, it is 
explained that when the programmer sets up an 
object, he specifies if the object is a write-once 
object or an updatable object. In particular, in 
block 50 of Figure 7, a distinction is made between 
processes (write; read) which can access an object 
and processes which cannot access an object, and 
between objects of the write-once type and other 
objects; in addition, it is specified in block 54 
whether the object may be read in a blocking manner 



Dl mentions only "write-once'' objects, either 
directly (Abstract, line 4) or indirectly (in 
connection with the programming language prolog 
(page 323, right-hand column, paragraph 2)). 

Consequently, the transactional blocking reading 
option is lacking. 



feature (c) : 



Feature (c) concerns selectable distribution 
strategies directed to the re-establishment or not 
of objects and processes (present description, page 
17, line 25, to page 18, line 8). 

In the present description, lines 5-12 of page 8, it 
is explained that "the selectable distribution 
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strategies (communication protocols) make it 
possible to adjust finely the reliability, 
availability, replication' behaviour or performance 
of the communication objects as required and wanted, 
for example, by means of protocol flags, such as 
"reliable" /"unreliable" , which can be selectively 
determined . 

Regarding the aspect fault-tolerance, Dl mentions 
only that the model discussed therein basically 
involves the strategy of (stepped) reliability 
classes (cf., inter alia, right-hand column, second 
complete paragraph and Chapter 4.2, "Different 
Reliability Classes", which extends up to page 330) . 

As a whole therefore, the subject matter of Claim 1 
meets the requirements of PCT Article 33(2) and (3). 

6. Claims 2-9 lay claim to advantageous configurations 
of the subject matter of Claim 1 which also meet the 
requirements of PCT Article 33(2) and (3). 
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VII. Certain defects in the international application 



The following defects in the form or contents of the international application have been noted: 

7. Contrary to PCT Rule 5.1(a) (ii) , the description 

does not indicate in sufficient detail the relevant 
prior art disclosed in document Dl , so as to allow 
the reader to recognise the innovations introduced 
by the invention. 
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R 33436 
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PCT/AT97/00209 
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Prioritat 
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Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der erfinderischen Tatigkeit und 
der gewerblichen Anwendbarkeit; Unterlagen und Erklarungen zur Stutzung dieser Feststellung 

Bestimmte angefuhrte Unterlagen 

Bestimmte Mangel der internationalen Anmeldung 

Bestimmte Bemerkungen zur internationalen Anmeldung 
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Datum der Einreichung des Antrags 
13/03/1998 


Datum der Fertigstellung dieses Berichts 
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Prufung beauftragten Behorde 

Europaisches Patentamt 
W8l 0-80298 Munchen 
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Bevollmachtigter Bediensteter 
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PRUFUNGSBERICHT 



Internationales Aktenzeichen PCT/AT97/00209 



I. Grundlage des Berichts 

1 . Dieser Bericht wurde erstellt auf der Grundlage (Ersatzblatter, die dem Anmeldeamt auf eine Aufforderung nach 
Artikel 14 hin vorgelegt warden, gelten im Rahmen dieses Berichts als "ursprunglich eingereicht" and sind ihm 
nicht beigefugt, weil sie keine Anderungen enthalten.): 

Beschreibung, Seiten: 

1-66 ursprungliche Fassung 

Patentanspruche, Nr.: 

1-9 eingegangen am 16/11/1998 mit Schreiben vom 12/11/1998 

Z ichnungen, Blatter: 

1/22-22/22 ursprungliche Fassung 

2. Aufgrund der Anderungen sind folgende Unterlagen fortgefallen: 

□ Beschreibung, Seiten: 

□ Anspruche, Nr.: 

□ Zeichnungeni Blatt: 

3. □ Dieser Bericht ist ohne Berucksichtigung (von einigen) der Anderungen erstellt worden, da diese aus den 

angegebenen Grunden nach Auffassung der Behorde uber den Offenbarungsgehalt in der ursprunglich 
eingereichten Fassung hinausgehen (Regel 70.2(c)): 



4. Etwaige zusatzliche Bemerkungen: 

V. Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der erfinderischen Tatigkeit und der 
gewerblichen Anwendbarkeit; Unterlagen und Erklarungen zur Stutzung dieser Feststellung 

1. Feststellung 



Neuheit (N) 



Ja: Anspruche 1 - 9 
Nein: Anspruche 



Erfinderische Tatigkeit (ET) 



Ja: Anspruche 1 - 9 
Nein: Anspruche 



Gewerbliche Anwendbarkeit (GA) Ja: Anspruche 1 - 9 

Nein: Anspruche 
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2. Unteriagen und Erklarungen * - *t*r > 

siehe Beiblatt 

VII. B stimmte Mangel der internationalen Anmeldung 

Es wurde festgestellt, daB die Internationale Anmeldung nach Form oder Inhalt folgende Mangel aufweist: 
si he Beiblatt 
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Zu Punkt V 

Begrundete Festsfellung nach Artikel 35(2) hinsichtlich der Neuheit, der 
erfinderischen Tafigkeit und der gewerblichen Anwendbarkeif; Unterlagen und 
Erklarungen zur Stutzung dieser Festsfellung 

1) . Es wird auf das folgende Dokument verwiesen: 

D1 : KUHN E: "Fault-tolerance for communicating multidatabase transactions" 
PROCEEDINGS OF THE TWENTY-SEVENTH HAWAII INTERNATIONAL 
CONFERENCE ON SYSTEM SCIENCES. VOL.II: SOFTWARE TECHNOLOGY 
(CAT. NO.94TH0607-2), PROCEEDINGS OF THE TWENTY-SEVENTH ANNUAL 
HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, WAILEA, 
HI, USA, 4-7 , ISBN 0-8186-5060-5, 1994, LOS ALAMITOS, CA, USA, IEEE 
COMPUT. SOC. PRESS, USA, Seiten 323-332. 

2) Ein System nach dem Oberbegriff des Patentanspruchs 1 aus dem Dokument D1 
bekannt. 

3) . Ausgehend von diesem Stand der Technik ist es Aufgabe der Erfindung, ein 
neues System der ... angefuhrten Art vorzusehen, das die Erstellung von robusten 
verteilten Anwendungen ... in einfacher und zuverlassiger Weise ermdglicht, wobei die ... 
Nachteile bekannter Vorschlage durch besondere Transakti onskonzepte auf der 
Kommunikationsschicht sowie durch die Auswahlbarkeit von mehreren Verteilunqs- 
strateaie vermieden werden sollten ( vorliegende Beschreibung, Seite 5, 3.Abschnitt ). 

4) . Diese Aufgabe wird im wesentlichen dadurch gelost, dal3 

(a) alle Koordinationsserver hinsichtlich der Grundfunktionalitat eines verteilten 
Objekt-, Transaktions- und Prozessmanagements identisch sind und zusammen 
ein globales Betriebssystem festlegen; da(3 

(b) zumindest einige der Objekte aktualisierbare Objekte sind und die zur 
Erweiterung der lokalen Softwaresysteme vorgesehenen Funktionen ein 
transaktionales blockierendes Lesen der aktualisierbaren Objekte vorsehen und 
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die Prozesse zum Zugreifen auf ubergebene Kommmunikationsobjekte autorisiert 
sincl, und daB 

(c) zur Verwaltung der Kommunikationsobjekte Verteilungsstrategien vorgesehen sind, 
von denen Anwendungsprogramme unabhangig sind und die hinsichtlich der 
Wiederherstellbarkeit Oder Nicht-Wiederherstellbarkeit von Kommunikationsobjekten 
und Prozessen wahlbar sind. 

5). 

Zu Merkmal (a): 

Die aus Merkmal (a) resultierenden Vorteile sind in der vorliegenden Beschreibung auf Seite 
6, Zeilen 12 bis 25 beschrieben. 

Merkmal (a) ist der Druckschrift D1 nicht zu entnehmen. 
Zu Merkmal (b): 

Merkmal (b) sieht aktualisierbare Objekte ( update-able objects ) vor, die transaktional und 
blockierend gelesen werden konnen ( vorliegende Beschreibung Seite 13, letzte vier Zeilen 
bis Seite 14, Zeile 28; Seiten 21/22 Abschnitt: Anlegen eines Objekts; Seiten 36/37 Abschnitt: 
Transaktionales Objekt-Lesen ). 

In den Zeilen 7 bis 10 auf Seite 21 der Beschreibung wird ausgefuhrt, daG beim Anlegen 
eines Objekts spezifiziert wird, ob es sich urn ein write-once Objekt oder urn ein update-able 
Objekt handelt. Speziell wird in Block 50 der Figur 7 wird unterschieden, ob ein ProzeB 
( Schreiben; Lesen ) auf ein Objekt zugreifen darf und ob ein Objekt vom Typ write-once ist; 
ferner wird in Block 54 unterschieden, ob blockierend gelesen werden soli. 

In Dokument D1 sind lediglich u einmal beschreibbare " Objekte ( write-once-objects ) 
unmittelbar (Abstract, Zeile 4 ) oder mittelbar ( in Zusammenhang mit der 
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Programmiersprache Prolog ( Seite 323, rechte Spalte, 2. Absatz ) ) angesprochen. 
Dementsprechend fehlt die Option von transaktionalem blockierendem Lesen. 
zu Merkmal (c): 

Merkmal (c) betriffl wahlbare Verteilungsstrategien, die auf die Wiederherstellung oder Nicht- 
Wiederherstellung von Objekten und Prozessen gerichtet sind ( vorliegende Beschreibung 
Seite 17, Zeile 25 bis Seite 18, Zeile 8 ). 

In der vorliegenden Beschreibung kann man in den Zeilen 5 bis 12 auf Seite 8 lesen, daB 
" durch die wahlbaren Verteilungsstrategien ( Kommunikationsprotokolle ) ein Fein-abstimmen 
von Zuverlassigkeit, Verfugbarkeit, Replikationsverhalten bzw. Performance der 
Kommunikationsobjekte je nach Bedarf und Zielsetzung moglich ist, z. B. durch wahlweise 
bestimmbare Protokollflags, wie " zuverlassig ( reliable ) " / " nicht zuverlassig 
( unreliable ) ". 

Bezuglich des Aspekts Fehlertoleranz ist der Druckschrift D1 nur zu entnehmen, daB das dort 
behandelte Modell grundsatzlich auf der Strategie einer ( abgestuften) Zuverlassigkeit beruht 
( vgl. u. a. Seite 329, rechte Spalte, zweiter " vollstandiger ■ Absatz und Kapitel 4.2 " Different 
Reliability Classes ", das sich bis auf Seite 330 erstreckt ). 

3 Insgesamt ergibt sich somit, daB der Gegenstand des Anspruchs 1 den Anforderungen des 
Artikeis 33(2) und (3) PCT genugt. 

6). In den Anspruchen 2 bis 9 sind vorteilhafte Ausgestaltungen des Gegenstands des 
Anspruchs 1 beansprucht, die ebenfalls den Erfordernissen des Artikels 33(2) und (3) PCT 
genugen. 
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Zu Punkt VII 

Bestimmte Mangel der internationalen Anmeldung 

7). Im Widerspruch zu den Erfordernissen der Regel 5.1 a) ii) PCT wird in der 
Beschreibung der in dem Dokument D1 offenbarte einschlagige Stand der Technik nicht 
detailliert genug angegeben, die es dem Leser ermoglichen, die Neuerungen der Erfindung 
zu erkennen. 
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Patentanspruche : 

1. System zur Koordinatioh verteilter . Programme , Dienst leistun- 
gen und Daten mit Hilfe von Anwendungsprogrammen in einem Netz- 
werk mit Rechnern, auf denen lokale Sof twaresysteme (LSYS) (18, 
19, 20) bedienende Koordinations -Server (CoKe) (21, 22, 23) lau- 
fen, wobei gemeinsame Objekte (9) als Kommunikat ionsob j ekte zum 
Austausch von Nachrichten eingesetzt und Transakt ionen zur Rea- 
lisierung von Kommunikat ion verwendet werden, und die Kommu- 
nikationsobjekte (9) durch Obj ekt ident if ikat ionsnummern (OID) 
eindeutig ident if iziert werden und nur Prozesse mit einer Refe- 
renz auf ein Kommunikationsobjekt auf dieses iiber den jeweiligen 
lokalen Koordinations -Server zugreifen durfen, wobei die lokalen 
Sof tware-Systeme (18, 19, 20) zumindest durch Funktionen zur 
Kontrolle von Transakt ionen, zum Anlegen, Schreiben und Lesen 
von Kommunikationsobjekten, sowie zur Erzeugung und Uberwachung 
von eindeutig identif izierten Prozessen erweitert sind, und wo- 
bei die Kommunikat ionsob j ekte (9) mit Hilfe von Replikations- 
strategien verwaltet werden, 

dadurch gekennzeichnet , 

dass alle Koordinations-Server (21, 22, 23) hinsichtlich der 
Grundf unktionalitat eines verteilten Obj ekt-, Transaktions- und 
Prozessmanagements ident sind und zusammen ein globales Be- 
triebssystem (24) f estlegen, 

dass zumindest einige der Objekte aktualisierbare Objekte 
sind und die zur Erweiterung der lokalen Sof twaresysteme (18, 
19, 20) vorgesehenen Funktionen ein transakt ionales blockieren- 
des Lesen der aktualisierbaren Objekte vorsehen und die Prozesse 
zum Zugreifen auf ubergebene Kommunikat ionsob j ekte autorisiert 
sind, 

und dass zur Verwaltung der Kommunikat ionsob j ekte (9) Ver- 
teilungsstrategien vorgesehen sind, von denen Anwendungspro- 
gramme unabhangig sind, und die zumindest hinsichtlich der Wie- 
derherstellbarkeit oder Nicht -Wiederherstellbarkei t von Kommu- 
nikat ionsob j ekten ( 9 ) und Prozessen wahlbar sind . 

2. System nach Anspruch 1, dadurch gekennzeichnet, dass bei der 
Wahl der jeweiligen Verteilungsstrategie eine Basis -St rategie in 
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Verbindung mit zusatzlichen, optionalen Strategief lags gewahlt 
wird. 

3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet , dass 
die lokalen Sof twaresysteme vom jeweiligen Koordinat ions -Server 
(21, 22, 23) startbar sind. 

4. System nach einem der Anspruche 1 bis 3, dadurch gekenn- 
zeichnet, dass Kommunikationsobjekte (9) , auf die kein lokal 
laufender Prozess mehr eine Referenz hat, vom jeweiligen Koor- 
dinations-Server (21, 22, 23) automatisch geloscht oder aus- 
driicklich f reigebbar sind . 

5. System nach einem der Anspruche 1 bis 4, dadurch gekenn- 
zeichnet, dass iiber die sich in ihrer Gesamtheit als globales 
Betriebssystem (24) verhaltenden Koordinations-Server (21, 22, 
23) heterogene Transaktionen bzw. Unter-Transakt ionen auf ver- 
schiedene Rechner (X, Y, Z) verteilt werden, 

6. System nach einem der Anspruche 1 bis 5, dadurch gekenn- 
zeichnet, dass ein nicht-blockierendes transakt ionales Lesen von 
aktualisierbaren Objekten vorgesehen ist . 

7. System nach einem der Anspruche 1 bis 5, dadurch gekenn- 
zeichnet, dass als transaktionales Pradikat das Schreiben in ein 
Objekt, das Starten einer Untertransaktion, das Verteilen eines 
Teils einer Transaktion auf einen anderen Rechner, das Spezifi- 
zieren einer Kompensat ionsakt ion bzw. einer Kommi t -Akt ion vor- 
gesehen sind . 

8. System nach einem der Anspruche '1 bis 7, dadurch gekenn- 
zeichnet, dass dann, wenn sicher ist, dass eine jeweilige Trans- 
aktion eine Vollzugsmeldung abgeben (kommitten) wird, eine Kom- 
mit-Aktion als Berechnung angestartet wird. 

9. System nach einem der Anspruche 1 bis 8, dadurch gekenn- 
zeichnet, dass unter den Funktionen fur Transaktionen ein pro- 
grammierbares Rucksetzen von transakt ionalen Operationen, wie 
z.B. das Lesen oder Schreiben von Kommunikat ionsob j ekten (9), 
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THIS PAGE BLANK (usfto) 



VERTRAG UBB5 
AU 



lE^DIE INTERNATIONALE ZUSAftflftg^ARBEIT 

p^ma GEBIET des patentwese|^ 



POT 

INTERNATIONALER RECHERCHENBERICHT 

(Artikel 18 s wie Regeln 43 und 44 PCT) 



Aktenzeichen des Anmelders oder AnwaJts 

R 33436 



WEITERES 
VORGEHEN 



siehe Mrtteilung Gber die Ubermittlung des internationalen 
Recherchenberichts (Formblatt PCT/ISA/220) sowie, soweit 
zutreffend, nachstehender Punkt 5 



Internationales Aktenzeichen 

PCT/ AT 97/00209 



Internationales Anmeldedatum 
(T ag/Monat/Jahr) 

24/09/1997 



(Fruhestes) Prioritatsdatum (Tag/Monat/Jahr) 

30/09/1996 



Anmelder 



KUHN, Eva 



Dieser intemationale Recherchenbericht wurde von der Internationalen Recherchenbeh6rde erstellt und wird dem Anmelder gemaB 
Artikel 1 8 ubermittelt. Eine Kopie wird dem Internationalen Buro ubermitteft. 



Dieser intemationale Recherchenbericht umfaBt insgesamt_2_ 



Blatter. 



[y] Daruber hinaus liegt ihm jeweils eine Kopie der in diesem Bericht genannten Unterlagen zum Stand der Technik bei. 



1 . Q Bestimmte AnsprOche haben sich als nicht recherchierbar erwiesen (siehe Feld I). 

2. Q Mangelnde Einheitlichkeit der Erfindung (siehe Feld II). 

3. r~1 I" der intemationaien Anmeldung ist ein Prptokoll einer Nucleotld- und/oder Aminosauresequenz offenbart; die intemationale 
— Recherche wurde auf der Grundlage des Sequenzproto kolls durchgefuhrt, 

| [ das zusammen mit der internationalen Anmeldung eingereicht wurde. 

| | das vorh Anmelder getrennt von der intemationaien Anmeldung vorgelegt wurde, 

I I dem jedoch keine Erklarung beigefQgt war, daB der Inhalt des Protokolls nicht Qber den 

1 — 1 Offenbarungsgehalt der intemationaien Anmeldung in der eingereichten Fassung hinausgeht. 

| | das von der Intemationaien Recherchenbehorde in die ordnungsgemaBe Form Qbertragen wurde. 

4. Hinsichtlich der Bezeichnung der Erfindung 

Py] wird der vom Anmelder eingereichte Wortlaut genehmigt. 
[ | wurde der Wortlaut von der Behorde wie folgt festgesetzt. 



Hinsichtlich der Zusammenfassung 

| y | wird der vom Anmelder eingereichte Wortlaut genehmigt. 

I I wurde der Wortlaut nach Regel 38.2b) in der Feld III angegebenen Fassung von dieser Behorde 
1 — 1 festgesetzt Der Anmelder kann der Internationalen Recherchenbehorde innerhalb eines Monats nach 
dem Datum der Absendung dieses internationalen Recherchenberichts eine Stellungnahme vorlegen. 



6. Folgende Abbildung der Zeichnungen ist mit der Zusammenfassung zu veroffentlichen: 
Abb. Nr 2 (xl wie vom Anmelder vorgeschlagen 



[ | weil der Anmelder selbst keine Abbildung vorgeschlagen hat. 
| | weil diese Abbildung die Erfindung besser kennzeichnet. 



| | keine der Abb. 
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Internati; 

PCT 



Aktenzeichen 

7/00209 



A. KLASSIFIZIERUNG DES ANMELDUNGSGEGENST ANDES 

IPK 6 G06F9/46 



Nach der Internationalen Patentklassifikation (IPK) oder nach der nationaien Klassifikation und der IPK 



B. RECHERCHIERTE GEBIETE 



Recherchierter MindestprOfstoff (Klassifikationssystem und Klassifikation ss ymbole ) 

IPK 6 G06F 



Recherchierte aber nicht zum MindestprOfstoff gehorende Veroffentlichungen, soweit diese unter die recherchierten Gebiete fallen 



Wahrend der intern ationaJen Recherche konsuttierte elektrontsche Datenbank (Name der Datenbank und evtl. verwendete Suchbegriffe) 




C. ALS WESEMTLICH ANGESEHENE UNTERLAGEN 



Kategorie 0 



eichnung der Veroffentlichung, soweit erforderttch unter Angabe der in Betracht kommenden Teile 



Betr. Anspruch Nr. 



KUHN E: "Fault-tolerance for 
communicating mul ti database transactions" 
PROCEEDINGS OF THE TWENTY-SEVENTH HAWAII 
INTERNATIONAL CONFERENCE ON SYSTEM 
SCIENCES. VOL.11: SOFTWARE TECHNOLOGY 
(CAT. NO.94TH0607-2), PROCEEDINGS OF THE 
TWENTY-SEVENTH ANNUAL HAWAII INTERNATIONAL 
CONFERENCE ON SYSTEM SCIENCES, WAI LEA, HI, 
USA, 4-7 , ISBN 0-8186-5060-5, 
ALAMITOS, CA, USA, IEEE COMPUT. 
PRESS, USA, 

Seiten 323-332, XP002046419 
in der Anmeldung erwahnt 
siehe das ganze Dokument 



1,2,5-8 



1994, 
SOC. 



LOS 



□ 



Weitere Veroffentlichungen sind der Fortsetzung von Feld C zu 
entnehmen 



□ 



Siehe An hang Patentfamilte 



° Besondere Kategorien von angegebenen Veroffentlichungen 
"A" Veroffentlichung, die den allgemeinen Stand der Technik definiert, 
aber nicht a Is besonders bedeutsam anzusehen ist 

"E" atteres Dokument, das jedoch erst am oder nach dem internationalen 
Anmeldedatum verfiffentltcht worden ist 

"L" Veroffentlichung, die gee ig net ist, einen Prioritatsanspruch zweifelhaft er- 
scheinen zu lassen, oder durch die das Veroffentlichungsdatum einer 
anderen im Recherchenbericht genannten Veroffentlichung belegt werden 
soil oder die aus einem anderen besonderen Grund angegeben ist {wte 
ausgefuhrt) 

"O" Veroffentlichung, die sich auf eine mOndliche Offenbarung, 

eine Benutzung, eine Ausstellung oder andere MaBnahmen bezieht 

*P" Veroffentlichung, die vor dem intemationaten Anmeldedatum, aber nach 

dem beanspruchten Priorrtatsdatum veto ffentlicht worden ist 



*T" Spate re Ver6ffentlichung, die nach dem internationalen Anmeldedatum 
oder dem Priorrtatsdatum veroffentlioht worden ist und mit der 
Anmeldung nicht kollidiert, sonde in nur zum Veret&ndnts des der 
Erfindung zugrundeliegenden Prinztps oder der ihr zugrundeliegenden 
Theorie angegeben ist 

•X" Veroffentlichung von besonderer Bedeutung; die beanspruchte Erfindung 
kann aJtein aufgrund diese r Veroffentlichung nicht ate neu oder auf 
erfinderischer Tatigkeit beruhend betrachtet werden 

"Y" VerflffentJichung von besonderer Bedeutung; die beanspruchte Erfindung 
kann nicht als auf erfinderischer Tatigkeit beruhend betrachtet 
werden, wenn die Veroffentlichung mit einer oder mehreren anderen 
Veroffentlichungen dieser Kategorie in Verbindung gebrachtwird und 
diese Verbindung far einen Fachmann nahel legend ist 

■&" Veroffentlichung, die Mitglied derselben Patentfamilie ist 



Datum des Abschlusses der internationalen Recherche 



11. November 1997 



Absendedatum des internationalen Recherche nberichts 



0 3; 12. 07 



Name und Postansohrift der Internationalen RecherchenbehOrde 
Europaisches Patentamt, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Bevollmachtigter Bediensteter 



Brandt, J 
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